Every Product has a place where it emerged from. Every Product Founder has a set of insights (ideas) or even specified document with the product vision about how it has to embed into the business environment and be competitive.
In business analysis it is called the Discovery Phase and the founder should actively participate so they don’t invent solutions before identifying user needs and product market fit.
At once the Discovery Phase is over and the founder gets a “rough understanding” what the product should be like, the most interesting things are beginning. When I say “rough understanding” it means the startup team is preparing for one big turbulence zone in the form of change requests and new features from the founder from sprint zero to MVP release.
After that, all the surviving team members are invited to the final demo to understand what they ended up with and who needs it. At this moment everything seems to be transparent, but for the founder the overall picture doesn’t match and they received just software with detailed documentation but not the product.
Project documentation and processes are like the laws or rules in your common life — you don't see them, but they are there. At the same time, no one reads the laws, but great things continue to be done — how does it happen? It's the same with product development processes. Founders want and must do great things, not to learn software development processes.
Use a product board
As a founder you should always look for ways to improve communications with your startup team and focus them on really important things. But through the different projects I reached the conclusion that founders are passionate only about their idea and don’t care about nuances of the internal development process and detailed requirements. I think it's obvious, isn't it?
That’s why I believe using a Product Board lets founders and teams integrate seamlessly into the development process, start thinking on the level of product vision and delivering valuable releases.
Combining a custom approach with well-known artefacts of business analysis, a founder can use several tiers of a product board and manage with 2 important things:
- Build a clear development communication process:
- Make a service design model to REALIZE quality of development,
- PROVIDE flexibility for changes based on users’ end-to-end scenarios and underlying values,
- HAVE a main focus on business issues,
- Being involved in business logic.
- Visualize and run 3 key elements of any project:
- PRODUCT ROADMAP: Artefact for a fast feedback about timeline, goals from sprint to sprint and from release to release, project health tracking.
- USER STORY MAP: For a simple understanding of the user journey, finding gaps, understanding what problems the user will be solving and how they go through your app.
- PRODUCT SANDBOX: A laboratory for making valuable features together with the team and having the right decisions, where you put different artefacts starting from simple sketches and ending with JTBD or diagrams.
If you want to look at a product board more closely or start to use one, follow the link to my template in Miro.
Product roadmap
The product roadmap allows Founder to capture the main milestones and development flows without unnecessary detail, but with a sufficient level of understanding of the current state of the project.
/w=3840,quality=90,fit=scale-down)
To do this, several tiers-flows are embedded in the product roadmap, each with its own role:
- Development sprint flow and Goals: Central parts of the ideal development process, but certainly not the only ones. Here a development team and founder create a mix of important tasks that are aimed at achieving the main goals, as well as additional work for further sprints.
- Product owner flow: Greatly helps you to focus on the founder’s tasks that must be solved in order to assist a development team. In this flow, it is important to go one step ahead of development sprint flow to eliminate blockers for the development team.
- Extra issues: Something unplanned, but very urgent. The flow where you can freely sound out in which sprints the team was overloaded and how it affected the development flow and what it eventually led to.
/w=3840,quality=90,fit=scale-down)
- Backlog: Everything that appears along the way of creating a product. An important point is that the founder or team shouldn’t store detailed requirements. The backlog flow in this case will be effective for managing current product ideas, new features, as well as for product tasks, business research, etc.
/w=3840,quality=90,fit=scale-down)
For quick orientation on the map, you can additionally use:
- Timeline of sprints;
- Colors and tags to define priorities and understand whether the task was closed or not;
- Marks for indication whether sprint goal was achieved.
Also use comments inside stickers to focus on specific problems or tasks. Communication in this form brings the team and founder closer thanks to the transparency of the process and leads to the desire to get involved and be proactive. And of course, such a whole picture helps you to track the state of the project and instantly change priorities keeping in the board history which tasks were postponed.
User story map
Working with this artefact helps the founder to see the whole picture easily. But in this case, the picture is at the level of user stories for understanding a series of events within one large user’s narrative. After all, no matter how well you understand the idea, the user story map will always help to find gaps, understand what tasks the user will solve and which way they will go.
/w=3840,quality=90,fit=scale-down)
To prepare better for creating a User story map, sometimes it’s good to have an additional End-to-End scenarios at a very high level to understand things like:
- Impact, motivation, triggers, reason. Description, goals, tasks;
- General business logic (basic steps);
- General acceptance criteria, value;
- Connection with further steps/scenarios, impact on parts of the product, connection with other systems;
- Errors and exceptional cases, Business rules (conditions, restrictions);
- Evolution, assumptions, backlog.
Product sandbox
In the product sandbox a founder can activate even more communication with the team through visualizing various diagrams, sketches, user personas and other things without waiting for detailed documentation to be written.
/w=3840,quality=90,fit=scale-down)
Using these visualizations a founder can fuel the interest of the development team for understanding how and why it should work.
Inspire your team
Inspiration instead of complicated management — that is exactly what should happen between a founder and their development team. That’s why in addition to the product board, you may follow these 6 essential things for product development to build a rocket and fly on it after the MVP stage:
- Just release something instead of thoughts about eternity.
- Think like the Persona, not the user.
- Visualize, communicate and design your own process.
- A user's problem is not always a reflection of value they want from your product.
- Allow the real world to test your idea.
- Lay down invisible threads for further architectural extensions.
Written by Alexey Yanushkevich