Guest Post by: Tofi Buzali (Mentee, Session 6, The Product Mentor) [Paired with Mentor, Andy Wadhwa]
As a product manager, it can be quite daunting to start a new software product from scratch. You have to work with different stakeholders to define the product vision and strategy, define the set of features that the product will have and figure out a rollout plan. All of this while guiding the development team, maintaining constant communication with stakeholders and potential customers, and optimizing for the product’s ultimate impact on its users.
I’d like to share with you some of the steps that have helped me define a product from scratch. At Proscai, I had the task to build a new Point of Sale (POS) solution for our clients and these three phases along with its corresponding documents helped me plan the development process and make sure all the team and stakeholders understood why, how and what we were building.
Define Product Vision and Strategy
Having a clear understanding of the reasoning behind building a product can go a long way towards smoothing the development process. Having a product vision and strategy can facilitate the definition and prioritization of features down the line, and ease the communication with stakeholders.
To frame the product objectives, you want to be clear about who you are building for, the problem they currently have and the currently available solutions. Here are some guiding questions and some resources that can help you work through these points:
- Who will use it? (Tools: Personas, Stakeholder interviews)
- What is the problem that this product will solve? “Fall in love with the problem, not the solution”
- Why is this problem worth solving? (Tools: Speed Dating can help you validate early ideas)
- Why will this product be better than existing solutions? (Tools: Contextual Inquiry, Competitive analysis)
I highly encourage you to not only think about these questions, but to also document your thoughts along the way. Putting this in paper will help you crystallize your ideas and allow you to expose them to the rest of your team to achieve a shared understanding of what you’re building and, most importantly, why you’re building it.
Jeff Patton’s Oportunity Canvas can be a good option for documenting the product objectives succinctly. I recommend you also add to this board the product vision as suggested by Roman Pitchler’s Product Vision Board. The vision of the product should answer these questions: What’s the motivation for creating the product?, What change will it bring to the world?
In my own experience, this opportunity canvas and the product vision definition forced me to think about aspects I had not considered such as the cost of building and of not building this new system, and made me analyse how the proposed solution could support future hardware devices. After sharing this document with the team, we realized the needed backend infrastructure would also accelerate the development of future products.
Once you and your team have a clear understanding of why this product is worth pursuing, as well as some solution ideas, it’s time to think about the specific features that the product should have to meet its objectives and bring its intended impact.
A great way to develop the set of features is though a User Story Map. Running a User Story Map workshop with your team will give you a comprehensive list of features prioritized by different releases (you want to ocus on learning quickly), and you will have common understanding among the different people involved. You should think about including designers, developers, and even potential users to this workshop to encourage collaboration.
I encourage you to review Jeff Patton’s process for building the story map. Here are some additional tips that have helped me on each phase.
- High level map (the backbone and walking skeleton)
Focus on the bigger picture. What are the most critical tasks for the users? Think about the journey of users from start to finish. Start with the most critical user and then add additional users.
Work through the body of the story map. Think outside of the box and go for quantity and not quality. Think about “what if’s..” and approach the exercise with a ”Yes, And..” mentality.
Prioritize each story with the most important stories at the top and the less important at the bottom of the map. Now’s the time to evaluate which features are worth pursuing first.
- Slice Out Releases
Slice the map in different releases. The first slice would be your MVP. Make sure that each release represents a functioning prototype.
By the end of the workshop you should have a map that looks like this, where each lane corresponds to a different release.
The User Story Map is great to have a clear and visual understanding of what the product will look like from the point of view of the user, and to list out the set of features that need to be developed. However, the map can be quite sizeable and you often want to have a short document with a summary of the releases involved. This is where Roman Pichler’s GO Product Roadmap comes in handy.
The Goal Oriented Product Roadmap will keep track of every iteration defined as part of the prioritization of your Story map along with a release date for each iteration, its goal, a list of high-level features, and a set of metrics.
Both the GO Product Roadmap and the User Story Map will describe the same picture but at two different zoom-levels. The first will help you keep track of your product’s roadmap as you move forward with each release, and the second will give you a detailed view of the user stories or features that your team needs to develop.
This roadmap document will also get you thinking about your strategy for testing your product on each release and the metrics that will track that goals are met at each iteration.
By now, it should be clear that this is only the planning phase, after which the development needs to be started. However, having a strong understanding of the objectives, features, and roadmap for the next months will give clarity to the development team and confidence to stakeholders. There are inherent risks to starting a product from scratch, but this planning phase will give enough head start to the team to start and a framework for the inevitable changes to come.
Tofi has a Masters Degree in Human Computer Interaction from Carnegie Mellon University. Based in Mexico City, he’s currently in charge of Product Management and Growth at Proscai. On his free time he enjoys tinkering with hardware, traveling and aerial photography.
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Check out the Mentors & Enjoy!
The Product Guy