Essential framework and templates for Product Managers

For new product managers or in startups with newly formed product teams, the building roadmap is their first kick at having the influence of the company direction. You might be super excited to go away for 2–3 weeks, conduct market research and come back with a colourful looking roadmap. This form of road mapping is what industry claims as standard but I have seen this fail badly. Creating a product roadmap and getting everyone on board and communicating it and iterating on it is a ton of work and it quickly falls out of sync.

I have had a fair share of experience working at enterprise and startup level companies. There is already a huge lead time and process before any roadmap gets approved by management and gets to the development phase. If you think about startups and think they might be agile (fast-growing and react to market fast enough etc), you will be much surprised. In one of my recent organizations, we had a newly formed product team and company never had a proper product roadmap so the PM team decided to go for an offsite for 2 days and create the roadmap. We came back from the offsite and communicated the roadmap to the wider audience in the company. Their immediate reaction was we cannot do this. Even though we convinced them that the timelines are only rough and can be moved. It was so hard to gain engineering’s trust, secondly, sales and other departments started holding engineering teams accountable to the dates mentioned on the roadmap which made the teams even more uncomfortable and caused friction.

Most companies follow this structure:

1. Ideas: are gathered mostly by the PMs from various sources, customers, support, customer service, and markets. These ideas tend to pile up over time and every few months PMs tend to prioritize those as per the business goals
2. Roadmap: is something most companies want to have to show off to cross-functional teams and keep them informed. Truth is that anything beyond a quarter is hard to plan for, situation change, business priorities can change, etc.
3. Projects (Features): most companies feel they are truly Agile but in fact, the agile processes don't come into play until the later parts of the development process. Everything up to this phase project planning, conducting user research, wireframing and design is mostly done in the waterfall approach.
4. Execution: this is the phase where agile sprint work happens and companies think they are agile enough but a project takes 3 months to complete and release with little feedback.
5. Launch: after launch, hoping to see metrics change but it doesn't happen. There is not enough validation done at different phases in the earlier phases to mitigate risks. By the time launch happens the actual feature might not even be truly solving the users' problem.

So what can you do? Below are some frameworks and templates that will help you track the progress and help with validation.

Discovery

• There are a few common mistakes that rookie product managers fall victim to. Your focus should not be only about gathering problems from stakeholders in the company and current/prospective clients. Example: Sales, Customer Support.
• You should be focusing on the future of what needs to be addressed not just for current clients or prospects. Thinking ahead of the game gives you opportunities to be disruptive. If not, other companies in the market are going to step ahead of you and seize the customer's attention.
• Discovery should be an activity that is ongoing no matter what other features are being developed or code-freeze period.
• Not Including lead developer and designer in the process will cost you when you drop a new feature request to the team. A team that doesn't have enough context on why they are building a feature, will not be motivated enough to imagine creative ways to solve the problem.

A good framework you can use is to map problems using the above template helps you prioritize better. It is important to tightly tie all the features and ensure a feature at least contributes to 1 of the final goal of the organization. This framework will help you communicates the impact it makes so that all the stakeholders can understand easily why you are developing a certain feature.

Feature One Pager Template

Create a feature poster using this template to figure out the right way to tackle a problem, define feature scope, and guide your work. Get all your teams to use this same template to define their features so stakeholders can easily understand the context and business case for your team’s portfolio of features.

Product Roadmap

A high-level product roadmap can be used for alignment across the whole product team for short term and long term. Short term focus should be the next quarter, what goals does the team need to achieve. Long term can be few quarters into the future or 2 years, planning for anything beyond that is not worth it because market changes, company vision changes too fast.

Depending on what kind of role and company you are in:

• You as a solo PM at a startup on the product having full agility on what goes onto the roadmap. But required to get executive approval on priorities.
• You as part of PM team with a Product Director, in charge of a part of the product. You prioritize the roadmap for your part of the product but work together with the whole team to create a product wide roadmap.

OKRs (Objectives and Key Results)

Objective: Get over 10000 new signups

Key Results:

• Improve signup conversion rate by 10%
• Launch new one-click process to be used by 25% of new signups

To achieve an objective, you should set key results that you need to accomplish. OKRs give teams a structure for creating quantifiable objectives and measuring progress toward them. Your team should also get together and review your OKRs frequently. You should see how your team is progressing toward these goals.

Execution

The team should be used to being agile enough to switch context between different problems. You should not hand off a big feature with (PRD) written and throw over the wall and expect a feature delivered at the end of 3 months.

Accounting for GOOD, BETTER, BEST case scenarios to solve a particular problem. You might not always need the BEST case solution to solve a particular problem if it applies to only 30% of your current customers. This will help you save engineering teams valuable time to work on other prioritized problems.

Would love to hear feedback if the article has helped. Connect with me LinkedIn if you want to chat further.