In each entry in this “conversation” series I talk to a designer/product manager/engineer on a topic. I want to make basic practical skills education transparent and free.
Today I am speaking to Ravi Akella who currently runs the product team at the Digital Manufacturing Group at Autodesk and is on the PM Leadership Team at Autodesk. His team of product managers focus on engineering simulation technology - modeling, analyzing and visualizing real world phenomenon like response of machines and structures to loads, fluid flow, 3D printing of metals etc. He previously led the product management team for AutoCAD as well. For context, Autodesk is a 9000+ person B2B software company with millions of paying users.
Your product is in a mature stage, how do you develop a product roadmap to enter a new industry?
This depends on the product and where it lies in its product lifecycle because the primary goal of product management is to align development efforts with business goals. Let’s take the example of a roadmap for a product that is widely used like AutoCAD to better serve a new industry while maintaining and iterating on the many industries it already serves.
We look across the industries(or segments) where the product is currently used and we look through the inputs from stakeholders like customers, sales, support, etc. to understand which industries to prioritize to meet our business goals. We then focus on the target industry and do research to understand the problems and pain points in that industry and come up with personas — which are essentially groupings of real people having the problem we will solve for — and the ‘jobs to be done’ which the goals that these people seek.
"Once we have have a set of problems we try to group them into themes that are meaningful to the target personas. In some companies, these themes are called initiatives. Essentially you look across all the themes and then prioritize which ones to focus on to deliver the most value to the customers and business."
Themes are then broken down into Epics which in turn are broken into user stories and ultimately tasks for the engineering team.
Example themes we have had in the past are “Collaboration” which meant improving how people share drawings while aligning with the processes and protocols within the target industry or “Continuous Adoption” which was about how to make it easier and less disruptive for customers to adopt the latest versions of the software.
"Look across all the themes and then prioritize which ones to focus on to deliver the most value."
So the steps to arrive at the roadmap for a new industry is:
Research → Industry -> Personas -> Problems → Themes →
Epics → User stories → Tasks
I have been on teams that have used tools like ProductPlan and Aha to manage the inputs to a roadmap. Some of these tools are designed for smaller companies with less specialized roles but there is subset of capabilities that work well for PMs to do upfront product planning in larger organizations. Eventually, of course, most teams manage the Epics and User Stories in Jira that is used across functions by PMs, Design, Development and QA.
What are the key inputs for your roadmap?
Most products that I have managed at Autodesk are mature and have hundreds of thousands or millions of users. This means the inputs to the Product Managers come from number of sources like:
- The Sales and Technical Sales teams
- The Customer Support teams
- Directly from customers: through proactive or reactive conversations, interactions at events, forums (other online channels) where we capture their feedback.
- Through customers reported issues (via the Support channels)
- Feedback from beta users: We run a lot of betas and get feedback from our customers on pre-release software
- From our executives: They usually have inputs from their own interactions with customers
- Company-wide mandates: These are highly weighted and an example can be a common component (like new licensing) that needs to standard across the entire portfolio. This kind of work just need to get done and is justified because of the value generated to the company through standardization and usually supported by senior stakeholders.
"Regardless of the source of the input, the PM has to boil it down to the problem that needs to be solved and the personas that benefit from the solution. Apart from the inbound channels PMs also have to go looking for problems in the data generated by their products. Good PMs are always proactively looking for problems. And, make sure you make time for that and talk to customers directly."
What are the different types of personas?
"For B2B products, the personas are not always straightforward and there isn’t just one persona."
It boils down to remembering whose problem you are trying to solve and value delivered by solving that problem.
The personas we keep in mind are:
- User personas: These are the users that are ultimately using the product. In complicated workflows there are many different user personas involved
- Buyer personas: These are the people who are buying the product. In B2B it’s different, the person who’s using the product might not be making the buying decision
- Internal personas: An example of this can be your internal development team when you make investments to make it easier for them to release new code or reduce technical debt
- Sales team personas: This one is unusual but sometimes you need to solve problems for people who sell your product. For example, if you need to development work to consolidate the product offerings, improve cross-product interoperability and make it easier for sales to credibly sell it — maybe consolidating many different individually priced modules into 3 tiers etc.
"The key thing to watch out for, especially in the landscape of B2B software, is the priority that is put on the buyer persona. Prioritizing the buyer persona too much and not focusing on the user personas runs the risk of making the product hard to use, which is usually why some B2B products are so hard to use."
What is your prioritization framework?
We do our prioritization in two steps. I have arrived at this model after years of tinkering and I am sure there are still many ways to improve it; I am always looking for feedback from my team of Product Managers to enhance it.
"It is key to do the problem prioritization first and then prioritize the solutions/feature ideas."
Once you have the problem for the personas in the target industry, list them out and score them on the following attributes (on a scale of 10 or similar):
- Severity (how big is the pain) — Problem severity is about customer pain and you have to know the persona intimately to assess it.
- Pervasiveness (the frequency) — For pervasiveness you have to know the common trends in the target industry or market segment.
Ideally, the PMs have a continuous flow of problems that they are logging into ProductPlan (or whichever tool) from all their input channels. The PM’s job is to look at them as often as possible and get as much data as possible to score the problems for prioritization. In my current team there are regular touch points with Sales and other stakeholders that give PMs the information needed to score the problems.
Once the problems are prioritized then we get our peers involved — design and engineering — and come up with solutions for each problem. This does not need to be a complicated or time consuming exercise just a quick conversation to think through options because each problem can have multiple solutions.
Each solution/feature idea can then be scored on the following parameters (on whichever scale makes sense — we currently use a 1 to 5 scale):
- Differentiation: This is how differentiated and unique our solution is compared to the competition. The PM has to do some research on competitive solutions to score this.
- Barriers to adoption: This is about being aware of potential barriers to adoption for the solution- the lower the score on this one, the better. For example if the solution requires customers to take special training or buy new hardware or change entrenched processes, there will be significant barriers to adoption — you have know the customers’ environment and processes to think through this one.
- Cost: This is the engineering effort required — the lower, the better. Keep in mind there is always margin of error here since these are based on quick conversation and not detailed estimation.
- Risk: This is how risky the solution is — the lower, the better — what are the dependencies that can go wrong? One type of risk is skills risk — if engineering is using novel technologies or components that have never been used or implemented before.
We use a simple formula — a weighted sum of all the positive parameters (severity, pervasiveness, differentiation) minus a weighted sum of the negative parameters (barriers to adoption, cost, risk) to come up with cumulative score for each solution. When teams first adopt this process, they iterate on the weights a few times.
Based on the scoring, you will have a prioritized list with rough estimates of engineering effort. If you can translate that rough estimate into story points and you know what your velocity is (how many points you can hit in a typical sprint) and the number of sprints you have in a release cycle, you come up with what you can credibly deliver in a particular release.
"One mistake that I have made before and I see PMs often make is they start prioritizing solutions or feature ideas without thinking about the core problem and alternative solutions. A problem can have many different solutions and it’s important to know and communicate to your peers which problem you are tackling. The product manager is essentially the problem manager."
"The product manager is essentially the problem manager"
Envisioning solutions is a cross-functional activity. You have to talk to design and engineering before prioritizing them — if you don’t talk to others you might just be guessing about what’s possible. Also, bringing in your peers and discussing the problems builds greater trust and commitment in your teams.
This is why Agile development makes sense. You will always have a margin of error when you are trying to figure out the market, the personas and the priority of their problems. Your judgement is based on the data you have and the time you have to gather that data — there is always an error and it’s gets worse when the Product Manager is stretched for time and resorts to guessing. The same is true for engineering estimates, even with the best, most experienced teams, there is always a margin of error.
"Envisioning solutions is a cross-functional activity."
Agile development breaks the work into small enough chunks so you can show it to actual customers and get user and market feedback early. We have betas where the customers are using pre-release code that is released much more frequently than the usual release cycles so teams can learn from the feedback and course-correct.
"I always remind myself and tell PMs that it is possible to survive a hundred paper cuts but we might not survive a big flesh wound. We are probably always messing up to a certain degree so we should have a process that reduces the business risk of these mistakes and makes them smaller, easier to mitigate. Ultimately, Agile development is about resilience and reducing the wasted effort caused by errors in the planning phases — having the humility to check your perceptions with real customers on an ongoing basis."
The way you prioritize also depends on the phase of the business you are in. If you are in the growth phase then problems and solutions that drive new customer acquisition take a bigger priority (with the assumption you will be able to do the work needed to retain the new customers in time), if you have scaled the business and captured significant market share then retention and reducing churn becomes key.
"Have the humility to check your perceptions with real customers on an ongoing basis."
How do you manage stakeholder requests?
If someone asks for a feature or a solution (let’s build ‘X’ button) then it is important to use an open-ended discovery method like asking 5 why’s to get to the underlying problem — why do you need this button etc. One needs to be careful so that the requester knows that you are not stonewalling them — you need to have a trusted relationship with them so that they know you are just trying to get at the real problem. As a PM, if you can’t articulate the problem you are solving then you are not doing your job. That’s the only way you can convince everyone you work with — design and engineering need to clearly understand the problem and it’s priority and they will look to you for that.
Identifying the underlying problem isn’t always straightforward.
Sometimes customers might be asking for something that may have nothing to do with the real problem — their context might be set based on the current product and how a solution is currently implemented. A simple example from my past was when some users of AutoCAD wanted some buttons in the UI to have text labels instead of icons. The issue was not that they preferred text in general, the issue is that the current icons weren’t big enough/explanatory enough/ conspicuous enough for users to build muscle memory with them. You can either say yes I’ll build a toggle to show the text or you can dig deeper into the problem along with your peers from design.
Over the years, I have realized that product managers should be good at doing three things under pressure:
- Be optimistic: Paint the picture of a positive future for customers and the business they serve in a confident and trustworthy way.
- Have a nose for trouble: Believe that anything that can possibly go wrong will go wrong until there is credible feedback from real customers that the problem has been solved.
- Capture moral high-ground: In the throes of a project you must be ready to do whatever needs to get done to help your team deliver.
Part of all this is to listen very well and be humble. If a stakeholder is disappointed, find the conflict early, address it directly and resolve it as soon as possible. Everyone changes their mind, the potential for conflict is constant but you can have constructive conflict in a respectful environment.
"The potential for conflict is constant but you can have constructive conflict in a respectful environment."
Misalignments and miscommunication happen all the time — the key is to calmly work through them without getting defensive. At the same time, you cannot do decision making about product by consensus. Someone somewhere is always slightly mad at you — you have to open and aware but know that this is a normal state of affairs — it might actually mean you’re doing a good job.
Additional Resources:
Definition of a problem template from Marty Cagan
Assessing Product Opportunities | Silicon Valley Product Group
Photo credit: Andrew Welch
This article was originally published on Romy's Medium page.
