How we manage our product roadmap

The screenshot here is our company Trello board, where we manage our product roadmap. We are extremely lucky in that our thousands of happy customers give us a steady stream of suggestions for new features and improvements, which we used to just throw on this board.

However, that soon lead to stagnation, and I would become paralysed with indecision whenever I looked at the board. It all seemed too much, and overwhelming and I never knew where to begin, or to stop.

How did we solve this? I mean, we still had to capture our customer’s wishes, but it was leading to a literal wall of things to do, and the more we added to that wall, the less chance there was of things happening.

Here is what we did.

Step one was to basically stop the development team from looking at this board at all. And that includes myself.

Step two was to get our Customer Success team to start managing the cards on the board, and to do it in a deliberate and disciplined manner. After all, the CS team were the ones talking to the customers during sales, onboarding and training calls, so they were at the ‘coal face’ as it were, and knew the exact challenges that our customers were facing.

The first thing we did, was to split the board into three logical sections. The left section is where incoming cards go to be evaluated and prioritised. The middle section was for recording progress, and the right hand section was for long term ‘back burner’ tasks.

Our current column layouts across the screen are:

• New - To Triage

• To Discuss

• Scoping

• Planned (Next 3 Months)

• Doing

• Done (Customer to be advised)

• Done (Completed)

• On Hold

• UX Improvements

• Column for each module in our app, i.e. Leave Management, E-Signatures

Cards pretty much move from left to right on here. Let me explain how.

The leftmost column is our ‘Triage’ column. Any new suggestions, comments or bug reports will go in here first, without any judgement or pre-conceptions. It is a column to ‘brain dump’ anything that comes through our support ticketing system or direct emails to CS team members.

It is important to note that any items the CS team adds as a result of a customer issue or request, all have a link to the relevant ticket in our HelpScout support ticketing system so we can cross refer back to the original conversation.

Once a week or so, the CS team will get together and go through this Triage column. They will decide what requests are important or critical, as well as see if any of the new cards are duplicates of older requests.

Things that they decide will be worked on will be moved into the next column, which is called ‘Scoping’. This column has a set process of itself, in order to scope out exactly what changes will be required in our system. The task has to pass scrutiny around security changes to our app, demand from other users, training and documentation required etc. A copy of the steps that a card in scoping has to go through is listed below:

Description

[briefly describe what the feature or fix should do]

Owner

[who is the owner of this story, who will be managing it moving forward]

Audience

[ ] Admin User [ ] Employee

Problem Space

[describe the problem or roadblock that this feature/fix will be solving. Are there any workarounds within HR Partner now, or are customers hacking around with existing functionality to try and accomplish their goals?]

Expected Outcomes

[describe what the final outcome or goal of this feature or fix will be. Try and go into details of the business problem that the end user will be solving]

Priority

[ ] Urgent [ ] High [ ] Medium [ ] Low [ ] Wishlist

Workflow

[what is the expected sequence of steps that the end user will have to go through in order to achieve their goals using this feature/fix? If there are multiple steps to prepare something, then process it, try and show a flowchart if possible]

Data Changes

[does this feature or fix make major changes to any data? Does it perform mass deletions or bulk modification of existing data that the user should be aware of? Should there be a way to reverse it if things go wrong?]

Permissions

[describe the permission restrictions needed on this feature or fix. Does it have to be restricted to employees in a particular Department or Location, should some employees be excluded from it based on any criteria etc.]

Interface

[does the interface need to be modified to suit this new feature or fix? If so, will it need a new menu or new screens created, or does it need a modification to existing menus or screens?]

Notifications

[what sort of notifications will be required for the end user? Will there be emails that need to be generated and sent to admin users or employees? Will any internal in app notifications need to be generated to let people know something has happened?]

External Factors

[does this feature rely on external tools, such as Slack or our API in order to be successfully used?]

Mockups

[try and include mockups or prototypes of any screens or workflows. Hand drawn, scanned/photographed and uploaded is fine, or sketches with any rudimentary drawing tool, or Photoshop, Figma, Sketch etc.]

Once the scoping process is completed, a decision is made as to whether the work will be done now, or at a later date.

This is when the card gets moved to either our Planned column or the Doing column.

At this point, the development team lead (myself) gets involved again. I look at the cards in these two columns, and set the priority from top to bottom. Now comes the time to take it to the next level.

We use a system called Phabricator for our development repository tracking, code reviews and bug ticket handling. Phabricator was originally developed internally at Facebook before being spun out on its own. Some people find it too technical, but I’ve used it for years and love it (even though the development company in charge has shuttered and stopped working on it as of August 2021).

When a card is to be worked on, I create a ticket in Phabricator and assign it to the developer that I want to be in charge of the ticket. Within the Phabricator ticket, I paste the link to the Trello card, and on the Trello card, I enter the Phabricator ticket number as a cross referencing mechanism.

The Phabricator ticket reference in the Trello card.

Showing the Trello link in the Phabricator ticket.

This means that the CS team can dive into Phabricator and find the work progress status if needed, and the development team can also go back to Trello and see the customer support tickets relating to the task at hand.

This two way deep dive (and yes, all our team have access to all our systems as a default) is invaluable to us keeping track of the status of any work being done.

My main focus is keeping these tickets on track in our Phabricator system. Once the tickets are completed, and tested on our staging server, then they are closed in Phabricator, and the developer responsible for the ticket will have to go back to Trello and either move the card to the Done column, or if there are links to our support ticketing system on the card, then it is moved to the Done - Customer to be advised column.

The CS team will then, as part of their Trello maintenance routine, go through the cards on Done - Customer to be advices and send responses to our customers advising them that the bug has been fixed, or the feature they requested has been implemented.

This I think is the biggest shining light of our process - Our customer is kept in the loop from initial support ticket right up to the job being done and pushed to production.

At our current team size, this process seems to work really well for us. It will be interesting to see how it scales as we grow. We will probably need to look at other toolsets and integrations, seeing as how Phabricator is now end of life.

Would love to hear from other startups how you handle a complex and busy roadmap. Drop us a comment below.

Optimising bank working hours

Photo by Museums Victoria on Unsplash

This is probably an out of date concept these days, however if you ever ran a traditional business back in the 70’s, 80’s and 90’s as I did, one of the most frustrating things ever was trying to get my banking done over the counter.

Almost all businesses have to have cash floats, or make deposits etc. to ensure cashflow stays strong, or perhaps talk to a manager to make certain arrangements. I know I had to do this many, many times during my business life over the decades, however it always flummoxed me as to how bad the experience was.

You see, in Australia, banks didn’t really open their doors until about 9am. Then they would shut early - around 4pm, citing that their staff needed the extra time at the start and end of each day to cash up and reconcile etc.

The big problem with that, was that most business people couldn’t visit the bank except:

1. Before they opened their own doors early in the morning, or

2. After they closed up shop at the end of the day, or

3. During their lunch break

Because (1) and (2) was practically impossible, you used to get a massive rush during (3) when almost every business in town was in the bank to try and get things done.

Here is a rough timeline graph of the bank’s chosen working hours vs the customer demand during those hours:

As you can see, a lot of frustrated people on either end, and a lot of overworked, harried bank staff in the middle trying to deal with the uncommon rush.

Why didn’t banks ever implement a split shift system?

They could have easily split their staffing in half, and have half the team come in earlier in the morning to open up and do the morning cash processing, and offer counter service to businesses who needed to get their cash floats before starting the day.

Then, they could have had a ‘late team’ come in later in the morning to help the morning team cover the mid-day rush, and work later to finish cashing up and deal with businesses coming in after closing to deposit their daily takings.

They would still have had a full team on for the lunch rush (which would be lessened by taking care of the customer needs on either end of the day, with no additional staffing costs involved.

I would assume that workers with kids in school would prefer to work the morning shift and finish working when it was time to pick up their children from school. Alternatively, people who were studying or partying may wish to sleep in a little later and work into the evening.

As I said, this is probably all redundant now, in the cashless economy and online banking world, however it is something that I always thought about when I walked into a bank to do business, but ended up leaving in frustration and with a negative taste in my mouth.

The wrong birthday assumption

Many years ago, back in the late 80’s, one of my first big development contracts was to create a database for NAALAS - the North Australian Aboriginal Legal Aid Service (no longer around).

Basically, this organisation provided legal assistance for Aboriginal people to help them through the quagmire that is the Australian legal system. The database I would design would be a case management and recording system that would enable their legal team to keep track of the progress of their client’s cases through what could be a many year long arduous process.

On the surface, it was a fairly simple database design, and at the time, I designed it using dBase III before migrating it over to Clipper eventually.

But at the outset, I made one critical mistake in the schema design for the client record. I had all the standard ‘people’ fields such as first name, last name etc., as well as a standard date field to capture the birth date of the client.

And that was where things fell apart when we went ‘live’.

You see, there were quite a lot of Aboriginal elders on their client files, and it turns out that a lot of Aboriginal people born in outlying communities do not actually know the exact date of their birth. Most of them only knew the month and the year, and some older ones only knew the year!

But they still needed to capture as much as they could of the birth details, and dBase’s date field could not capture partial dates when the operators tried entering in 00/05/1958, or 00/00/1947 etc.

This means a last minute rush back to the drawing board where I had to break up the birth date entry field into three separate (optional) entry fields for the date, month and year, and then only complete the actual birthdate field programatically in the back end only if all three components were present.

Reports still had to be generated on these ‘dates’, i.e. all clients who were born between 1960 and 1970 etc., so there was some judicious workaround implemented in the system to still accommodate this using partial or complete dates.

It was an early lesson that stuck with me to this very day, and still influences all design decisions I make around database schemas and user interfaces.

Basecamp's house of cards...

Photo by Sigmund on Unsplash

Character is like toothpaste - it really only comes out under pressure (unknown)

I don’t know where I first heard the above quote, but the events of the last week have really shown how true this saying is.

I will start by saying that I have been an interested (but not rabid) fan of the journey that Jason Fried and DHH have been, building their startup called Basecamp. I started on my journey of building online SaaS system 20 years ago, when they first started the company. I had a further 20 years more experience of running a software consulting business before that, so I was intrigued, and a little surprised that two young lads could start an online software business that just seemed to go gangbusters out of the gate.

I guess that was the main thing that caught my attention - that it seemed so effortless, and looked like revenues just snowballed from day 1. Heck they even said that they were earning revenue before they had a chance to build in a billing and payment interface into the system! Something that I had never experienced at that stage.

As a developer myself, I admired DHH’s work with building the Rails framework. Though even back then, I found the framework to be a little too opinionated - much like the founders themselves. I grew to love the Ruby language, but not the Rails framework. Indeed my current startup, which is successful beyond my dreams, is built using Ruby (but on a different framework).

I used to read Jason and David’s blog posts, and over the years, I even bought a few of their books. However I always read their advice with a touch of reservation. They always struck me as being the guys that fell into a pond and came up with a Koi carp in their mouth and went “Oh, hey, let’s tell everyone else how to be great Koi carp fishermen like ourselves”.

Don’t read me wrong - I did respect a lot of the things they did, and how they rattled some of the embedded habits of running a business, but somehow, it all seemed to come from a charmed existence, devoid of any real challenges or problems that required some really creative problem solving.

As far as I know, the never had to deal with situations like:

• Having to make payroll for the team with $0 in the bank

• Having an employee go rogue and either embezzle funds from the company or conduct systemic abuse of another employee over time

• Having a founder/partnership separation that was acrimonious or came at the wrong time

• Having to deal with data loss or accidental customer data deletion due to bad internal practices

I have had to deal with nearly all the above in my 40 odd years of running former businesses. Some of them more than once. I wanted advice that came from the painful viewpoint of having experienced this and and had you staring at the possibility of the end of your company as a consequence. But when you are busy raking in the cash as Jason and David were, it is hard to listed to the “Oh, just do as we do and you will be just as successful” mantra.

The current events at the company have shown the fragility of the foundations that have brought the company to these dizzying heights. Fundamental issues with employee management have been ignored and seemingly plastered over with benefits and reinforcement of “You are lucky to be working at such a great company and being lead by such great leaders!”.

It seems though, that when push came to shove, and employees expressed dissatisfaction with a number of policies and people within the company, it all became too hard, and instead of confronting the problem head on and dealing with the issue, the decision to avoid it and offer band aid solutions was put forward. This seems not to have worked this time around.

Indeed, it seemed that at the ultimate “all hands” meeting, one founder put his normally opinionated personality into hiding and said he would offer no opinions, and the other founder attended from his bed, turned his video off and muted his mic and seemingly posted a slew of anti-Apple retweets during probably what was the most important meeting of his company’s existence.

Basecamp is a wounded beast now, and it will take some time to recover. I genuinely hope that they find their feet again, and that they learn from this, and that their company sticks around for another few decades. I hope that the employee’s who left find gainful and happy employment elsewhere, and I hope that Jason and David approach any future “lessons” they they wish to impart with a lot more humility. I also hope they also see fit to step down from the pulpit every now and then and ask for advice from those that came before them, rather than roll over every business legacy with their own thoughts of how things should be done.