Either you or someone you know has received a “Houston, we have a problem” email indicating that the company has taken a hit in online visibility because it doesn’t have a mobile app for their consumers. But, in order to develop an app that gets you where you need to go, with the least burden, you’ll need to create a roadmap for agile development.
This often results in recognizing the need to produce a Minimum Viable Product (MVP). This is a “version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time.”
Related: High-Level Differences Between MMP & MVP Product Development Strategy
As a Project Manager, I’m eager to help you make your app a reality. A roadmap of your vision during our pre-kickoff call or initial meeting helps me understand your needs for the life of the project. However, many clients believe that our “agile” approach means roadmaps aren’t needed. I get it, Agile methodology certainly simplifies adjusting to the inevitable changes that pop up. But, the process doesn’t exempt you from first identifying your intended objectives. Your “product roadmap” or “product vision” serves this purpose. It is NOT a promise or a firm plan of what will happen (well, unless your company has hired a psychic…which would be pretty awesome). Roadmapping is an easy-to-follow living document for stakeholders to visually digest the backlog and take a peek into the potential future of the product.
Now that you understand the purpose of the roadmap, let’s talk about how to get started building one that is unique to your needs. One that makes the most sense for your company.
Related: Developing a Mobile App Roadmap
Step One
Ask yourself these 4 important questions as the product owner:
- What is the problem we are trying to solve?
- Who will this app impact? (listing everyone – not just stopping at the obvious)
- How will we measure success?
- How does this tie back to our OKRs (Objectives and Key Results)?
Step Two
Once you’ve addressed those major questions, you can add more granular detail such as:
- Timelines
- Important dates for deliverables
- Key milestones
- Release dates
- Other important information specific to your company
Building a roadmap that addresses these questions will help keep you (and other stakeholders) focused, and weeds out techwaste or technical debt. For example, an overly excited stakeholder who may throw new features at you all the time may be more quickly refocused with the existing roadmap. (In fact, I highly recommend having your roadmap handy during meetings with these kinds of stakeholders). This gives you room to backlog new features and ideas so they can be analyzed and prioritized before altering the map.
KEEP IT SIMPLE
In closing, let’s just keep things simple. There’s no need to overthink roadmapping. Use the big four questions, add as much detail as you can, focus on the ‘now,’ and keep those tasks that are happening later on in the backlog. Then, the owner of the roadmap can make updates to align with changing priorities and goals. Remember that sharing your roadmap with all stakeholders helps keep communication open ensuring the product is heading in the right direction. And remember, this world is already complicated enough…roadmapping doesn’t have to be. Just have fun and get ready to celebrate your success with the understanding that your roadmap will help to get you there faster!
