The Cabify Product Development Process

How we use Trello (and other tools) for Product Management & Development

I joined the Spanish startup, Cabify this year as Head of Product, hoping to assist in their rapid expansion across Spain, Mexico, Peru and Chile. Together with the awesome Product team in Madrid, we’re trying to manage the technology challenges of a rapidly growing company entering new markets across 3 continents with a suite of web and mobile apps, which each have vastly different users. Our process* for gathering feedback, requirements, prioritising, specifying, designing and developing; is still a work in progress, but I think we’ve got the foundations of a great process for a small team (<10) and worth sharing with other teams out there.

*note that this process will work well for a small, cross-functional team and will likely not apply to product/engineering teams larger than 15

The Helicopter View

For Cabify, the process of getting a feature request or a bug into development and out to production spans 5 different Trello boards. Each of these 5 boards serves a different purpose, but they all come together to funnel the highest prioritised work to our development team and to maximise the speed of delivery into production.

The Trello Boards

Product Roadmap

This board is a left-to-right prioritised list of:

• Ideas we might like to develop
• Features we know we want to develop but are not yet high priority
• An ordered list of features that are next up
• Features that are currently in development

Once features are ready to move into the “Next up” column we begin to create more detailed cards on the next board — the Feature Factory. When a feature has been specified and is ready for development we link the feature cards on the Roadmap board to the detailed story cards we have created, so that you can always jump from the roadmap view into the detailed development view.

Feature Factory

This multi-purpose board is a holder of cards before they are ready to move into development. It means that this board is contains design cards, specification cards, small feature requests and backlog of cards ready to be moved over to the development board.

Issues/Bugs

This board is a log of bugs or issues identified, awaiting investigation or awaiting a greater importance before they are moved over to the development board.

Release Board

Each week, or each app release we move the list of cards that were delivered to production, over to the Release board so it is essentially a log of all the work done that’s now out in the hands of our users.

In addition to the boards we also maintain a “Prioritisation Scorecard” which feeds changes to the Product Roadmap. On the scorecard we rank upcoming and suggested features according to their revenue value, user value or value to the scalability of the business (the inputs to this scorecard are the user problems, business problems and opportunities we have identified, but we’ll save that for another post).

Where the magic happens: The Current Development board

The Cabify Current Development board contains the following columns:

Next Up

All cards have been prioritized to be worked on and include enough definition to start dev. Since this is already a prioritised list, it is usually fine that our team just picks up the card that best aligns with their skill set or what they have recently been working on.

In Dev

All cards that are actively being worked on by a developer. When picked up, each team member assigns an estimate of the complexity of the card (1–5) that we later use to calculate our weekly velocity. Our basic rule of thumb is that no-one should be working on more than one thing at a time, unless one of those cards is an urgent bug, or the cards are a part of the same larger feature.

QA

Cards are moved here when we believe the dev work is done. It is now time for our QA manager to push it to a testing environment or ensure we have a build version of an app to test. Our QA manager tries his best to break the feature and assuming all is well he will move it on to the QA Passed column.

QA Passed

These are cards are now assigned back to the developer who worked on them, awaiting them to push the code into production and out in the hands of real users.

Production

High five’s all round — this is the stuff we’ve pushed out into the real world this week.

App versions

When dev on one of our apps passes QA, it is queued up in the relevant app version column.When we have enough improvements to release a new version of the app this column moves over to the release board and we start a new app version column.

The Cards

• Feature — Any item of work that will improve the app(s) or add new functionality to the app(s) for internal or external users. Our feature cards must be written in the format of User stories, implementation hints and wireframes/designs where relevant.
• Tech Task — Any area of work that does not provide obvious value to an end user. Eg. Infrastructure task, security improvements or code cleanup.
• Bug — Something is broken, inaccurate or currently negatively impacting users. Bug cards should, where possible contain instructions so that a developer could reproduce the problem.

Our meetings

• Product Prioritisation (monthly) — This meeting involves input from our CEO/COO/CTO where the discussion is primarily around the Prioritisation Scorecard. The purpose is to review any new items that have popped up in the last month and ensure they are given their correct place in the pipeline. Following this meeting the Roadmap board is updated if necessary.
• Development prioritisation (weekly) — This is where we pull cards from the Feature Factory board over to the Current Development board. Ideally we aim to stick to the Roadmap priorities but sometimes tasks awaiting further definition or design mean that we are pulling in some smaller value items that we can deliver quickly to our end users.
• Standups (daily) — Admittedly this is one we still struggle to get right, particularly when part of our team works remotely. Nothing unusual here though, it is really just s chance to review the board to make sure the cards accurately reflect the status of the work or to bring up any issues/questions anyone might have with a card assigned to them.

The Tools

• Trello — Almost all of the action above happens in Trello. The speed and ease of use of it’s UI makes it tough to find an alternative. I have some gripes about the fact that it’s not specifically built for software dev and tough to pull data out of, but I think we’ve managed to bend and twist it to work for us. We also use a couple of Trello plugins (Projects for Trello, Card colors for Trello & Scrum for Trello) to make it a little easier to manage.
• Flowdock — This is our team communication hub and works just as well, if not better than Hipchat or Slack. We’re typically chatting about questions on the work in dev or lining up the next work (or posting memes).
• Flowdock plus Github/Hubot — We have a super awesome integration that allows anyone to push a Github branch to a test or production environment by posting a command in Flowdock. We can also easily see what is being pushed or merged as it happens.

Hints and tips

• Each of these steps in the process is as important as the other. Even with a great team, your development board will struggle without prioritized, defined cards being fed into it.
• Use a chat app. Even for teams in the same room. Is allows for more rapid feedback than posting on the board or (yikes) email, but does not interrupt active concentration like coming up to someone who is buried in code.
• Prioritize your bugs like this: Important vs not important. If it’s not important then don’t fix it. If a bug is important it will come back again, and if it doesn’t pop up again then it wasn’t important. You don’t have to fix everything.
• Monitor the time spent delivering value to users vs tech tasks vs bugs and make necessary changes to ensure the majority of the teams time is spent delivering new value to internal or external users.
• A good development card/task should describe the user/business value, the problem being solved, and the expected inputs and outputs. Keep the implementation instructions light.
• Talk — all the tools in the world can not replace a real conversation. It’s a great habit that each time a new task is picked up, a quick conversation takes place between the developer and the PM or tech lead to make sure all is clear. Chat is good, face to face/video call is better.
• Celebrate the wins, talk about the losses. This is something we have to get better at. In a fast paced startup with an endless pipeline of requests/problems/opportunities it can be hard to stop and look at the great job done, or review ways to improve — but it’s a necessary part of the process and makes for a happier, more efficient team.

The Cabify development process is still evolving and will continue to be tweaked as the company grows and the team expands, but I think we’re making great progress over the first few months.