Great. Now you’ve decided what idea you want to focus on and why it’s important to your consumers.
Next challenge: how do you start building your product?
You start with a grand vision statement of redefining an industry and changing people’s lives. Then you get to the tough part of figuring out how exactly you do that. Multiple opinions surface – Let’s build front-end first. Let’s build a scalable backend. Let’s go mobile first. No, no, web first. Is this a 1.0 or a 2.0 feature? Hey, we need marketing demo stuff ready quickly. What? Requirements changed again?
Chaos is inherent in startups. Any team will have a lot of conflicting ideas on what needs to be done. Managing all the inputs can be difficult.
Independent teams in larger organizations struggle with similar issues. They don’t have a VC to convince, but often need enough of a story to sell-in to senior management. As the core team keeps context switching between strategy and execution, there are often fresh debates on strategy, on whether something is ‘not right’ and a lot of muttering beneath the breath.
Some of the larger companies adopt a process of having a marketing requirements document followed by a product requirements document. This might seem like a lot of process overhead for a startup. But I recommend at least having a good product roadmap in place.
Why a product roadmap helps
It’s easy to scoff at a product roadmap, saying we’re such a small team – we don’t need it. But, having a clear document reduces much grief along the way.
A product roadmap is a priority order of features that your team will work on. It is a document that everyone can reference (and challenge!). It reduces
communication challenges and costly misunderstandings. It may feel like process overhead, but it more than compensates for the chaos you have to bear
A good product roadmap is also a great way to identify dependencies, so that you sequence your work for maximum impact. If your company vision is the ideal state for you to reach, look at the roadmap as the set of steps that will get you there.
I have worked with multi-site teams with different sub-teams building product components as well as smaller teams based in one site. The level of detailing differs in the product roadmap – multi-site multi-component teams require more detailed plans, as there are more pieces that fit together. In both situations, having a clear product roadmap and priority list helped everyone stay on track, and plan items like dependency charts, product features and analytics we wanted to capture.
Some benefits of a good product roadmap are:
How do you build a product roadmap?
Product roadmaps help bring clarity to the vision, as well as give details to execution teams.
Typically, you’ll end up creating different versions of the same priority roadmap, with different objectives
This version contains lesser details, but lays out the story better. It is an important means of communication when you present your idea to management
or for funding. This is also the document that execution teams can periodically check against to see if they are on the right track. A typical version consists of customer needs, landscaping to see what solutions exist, identifying why your product will be important, and a high level feature list of your product.
A high-level product roadmap for the case discussed earlier could be:
…and so on.
This is your execution list. I recommend adopting, or adapting, the SCRUM methodology. SCRUM involves building iterative and agile product, with teams focusing on potentially shippable increments of work. The link gives more information on the SCRUM process. The concept of user story from the SCRUM process is a great way of building your roadmap or backlog.
At its root, a user story consists of a user’s perspective and an expected outcome.
Some examples of user stories are:
I recommend using the same approach to capture other stakeholder feedback:
As a business analyst, I would like to see details of what product features are used the most.
As the next step, you would then detail out these user stories with what exactly needs to be done to implement a user story, and which teams would be involved. In this method, the entire product backlog is built not in terms of independent tasks for backend, web, etc. but in terms of what needs to be achieved for the consumer. A user story becomes a common means of different teams talking through a consumer problem to target, implement and test.
With a good backlog, you would also identify which stories need to be done earlier. For example, the alert system might be in use for alerting category
manager, shopkeeper, sales manager, etc. and so may need to be implemented before the others. This level of detail helps different teams estimate effort for implementation. This can than be consolidated to see when a product launch is technically feasible.
Some benefits of having everything captured in the roadmap are:
Point to note: the product roadmap is usually a living document, and there will be changes to the plans after you start implementation. This approach helps understand impact and plan changes better.
What has your experience with building product roadmaps been? Post your comments on the topic below or reach out to me on Twitter at @shrinathv.
Note: these are personal views of the author.