December 11, 2012

One of the most important aspects of product design and management is prioritization. There are only so many resources at a company's disposal at any given time that product efforts must be prioritized vigilantly lest a team end up spending considerable time producing sub-optimal or worse, misguided, work. This is especially true at a startup where resources are extremely constrained and product efforts can either suffer or benefit greatly from acute path dependency.

I've found that the simplest yet most effective tool to prioritize product developments is kanban, or at least my interpretation of it. A well-organized kanban board can help a team visualize what product ideas currently are or are not getting attention, by what team members, and why. It encourages a "lean" mentality by putting ideas into a sequence of design,  development and validation only when there is current capacity to do so. And yet it also provides a staging area for longer-standing ideas that await their turn for production.

You can use digital software to create a kanban, such as Trello, but I actually prefer old-fashioned notecards, tape and markers. To create one, you simply need these materials and a decent amount of wall space. You'll be writing down product ideas onto the cards and then taping them up on the wall under predefined columns and sections depending on where they belong. A big advantage of doing this on the wall is that you can very readily use the board during meetings to communicate product direction without having everyone burrow into their laptops. A wall-based kanban system is also more customizable on-the-fly.

Product ideas, corresponding to notecards that primarily display their label (e.g. "Daily Digest Email"), start off in the left-most "Icebox" column and move rightward through "Design", "Develop" and "Validate" columns as they proceed along the production process. Ideas start in the icebox because all ideas deserve justification before they get any significant attention from the team, and as the name suggests, the icebox is where ideas stay frozen (i.e. no one is working on them). Whenever you or anyone else on the team thinks of a clever new product idea, it should be put up on the board in the icebox because then it can be considered for production.

I like to divide the icebox into sub-columns for the organization of ideas by their primary purposes. A primary purpose should be determined for every idea, even if that idea serves several purposes, because otherwise it's hard to justify its enactment and later validate its success. You may find that the purposes you outline on the board vary from product to product, but for many products, you can boil them down to mainly user/customer "Acquisition", "Activation", and "Engagement". For example, the daily digest email example above should probably go under "Engagement" because the main hypothesis behind such an email would be that it could increase the engagement frequency and long-term retention of users. A different idea, such as "Send Invitations Page", could go under "Acquisition" because it's intended to help with viral distribution.

You can order product ideas under each column based on your current sense of their appropriate prioritization, but any such prioritization should be tentative since ideas ought to be pulled from the icebox as the result of iterative assessments about what's worth resources (perhaps as frequently as on a weekly or biweekly basis). It's also ideal to identify what measurable impact on the product will indicate success for an idea before it's taken out of the icebox and put into production (i.e. you could hypothesize that long-term user retention will increase 5% with the introduction of daily digest emails). Kanban is intended to help you prioritize by product ideas by potential impact, but this shouldn't be interpreted as creating a "waterfall" situation where ideas are prioritized concretely and deeply into the icebox. Otherwise, you'll find that you aren't properly making incremental product decisions based on the most up-to-date information at your disposal, and you could get yourself locked into unproductive product directions for months or more at a time.

Once it's determined that an idea should go into production – because it contains the greatest potential for addressing the most-pressing business needs (such as user engagement or acquisition) – its card gets moved from the icebox and into the "Design" column. This column in divided into two rows: "In Progress" on the top and "Done" below. An idea first goes into the "In Progress" row, which indicates that designers have begun actively working on its design. Once the designers have finished all anticipated design work for the idea, it moves to "Done", which is where it ought to stay, however briefly as possible, before moving into the "Develop" column.

Similarly to the "Design" column, the "Develop" column indicates when ideas are getting attention from developers, or engineers. The "Develop" column has two rows: "In Tracker" on top, and "In Progress" on bottom. Because I've used kanban to visualize product prioritization in conjunction with Pivotal Tracker for engineering prioritization, the "In Tracker" row indicates when a given product idea has been picked up by the engineering team and added to their own pivotal tracker projects, which allows them to break it down into specific engineering tasks. The presence of an idea in the "In Tracker" section of "Develop" rather than the "Done" section of "Design" indicates that its aims and designs have been explained and delivered to developers, and the idea is therefore in their court to proceed with execution. When they do start working on an idea (which should be quickly in a well-regulated kanban system), it moves to "In Progress" until complete.

Since kanban is best used with continuous deployment, there is no "Done" row for the "Develop" column; cards simply move to the "Validate" column, which indicates that their ideas have gotten deployed to actual users and are awaiting validation. The "Validate" column can be split into two rows if you have both a beta and live environment (i.e. when ideas get pushed into beta testing, they should go under a "Beta" row, and when they go fully live, a "Live" row). Notice that cards aren't simply taken off the board once they've been deployed, since the validation column is intended to remind a team that they need to follow up on whether the idea they built actually had its intended effect.

Deployed ideas stay in the validation column until it's determined that they succeeded according to plan, at which point they're removed from the board. But if they (perhaps more likely) failed or fell short, they are moved backwards through the board to whatever stage is deemed necessary ("Icebox" if the team gives up on the idea for now, "Design" if its failure is deemed a design shortcoming, or "Develop" if it's found buggy or incorrectly implemented). Because it's easy to come up with low standards for validating ideas post-production, you'd do best to use the exact hypothesis you stated originally for an idea when determining whether it validated successfully, even if that means leaving a card in the "Validate" column for an extended period of time to gauge its effect.

When you begin using a kanban board to track the execution of product ideas, you'll notice the bottlenecks in your overall production process. Cards may begin to pile up in the design, develop or validate columns, indicating that you need more resources in those areas if you want to produce so much at a given time. And if you can't add the required resources, you'll know you need to scale back how much you bite off or break down ideas into smaller chunks, with the goal of keeping each of your resources at full (but no greater) capacity.

If you begin using such a kanban board – hopefully to discuss product direction at regularly scheduled meetings – you'll inevitably find ways to customize it according to the needs of your particular team and product. And these customizations should be made with an eye towards augmenting the board's ability to prioritize the highest-impact product ideas and speed up the process by which they go from design to validation. If you manage to do this, you'll gain peace of mind that you're making the best product choices possible and following through on them effectively.