Roadmaps for B2B companies
Conversation with Nathan Creswell, Product Director at Zuora
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 with Nathan Creswell, a Product Director at Zuora. Nathan has been a B2B product manager his entire career — previously at Salesforce and now at Zuora, which is a late stage startup. Nathan’s team is in charge of the front office applications and integrations to the core billing product. For context, Zuora is a subscription management platform for SAAS billing. The product team is divided among 3 product lines — Billing/Finance, Insights and the Zuora Platform.
How do you structure your roadmap for the team?
My roadmap is a mixture of three areas:
- Core features — Surfacing core Zuora features in the front office applications for my product area
- Strategic features — Features that are implemented because it will make the product better, get more revenue or give you a competitive edge
- Maintenance features — Small things which are the known and part of day to day product management — bug fixes and technical debt
Who are the stakeholders that provide input into the roadmap?
There are two kinds of stakeholders you deal with — internal and external stakeholders.
Internal stakeholders can be anyone within the company — usually they are Sales, Sales engineers and Customer success managers. External stakeholders are your customers.
As the requests come from various stakeholders, it’s important to know that customers suggest solutions but don’t necessarily describe the problem. Internal stakeholders may give good feedback on the actual problem the customers are having. For example, a customer complaining about an issue may just say we need a button in the left corner, but the button may not be the right solution and the right solution may be a huge capability.
A good product manager does not have a knee jerk reaction to feature requests. Always have a lens on who the person is that is asking for the feature, what they are saying and where they are coming from — that fundamentally affects prioritization.
How do you prioritize features after you have the input?
Prioritization is part art and part science. It’s very hard to say “this group takes priority over others in the company.” For Sales, if you don’t do what they need, growth is affected, which is very important for a startup. Customer success is responsible for the post-implementation happiness of a customer, so if you don’t give them priority, then customer satisfaction goes down and they may even leave you for a competitor.
With B2B software it’s hard to run an a/b test to test things because you don’t have enough data. At the same time you will have quantitative data in the form of patterns of requests. Once you see patterns, try and delve into dimensions — where it’s coming from, who it’s for, what it benefits. That will help figure out priorities. Prioritization is about making tradeoffs, cost benefit analysis and knowing which bucket it belongs to in the above (core/strategic/day-to-day).
An example of a feature I have done that evidences these things was a Rules Engine, which was a capability to automate the addition, update and removal of products on a Quote. We noticed a number of customization requests come through from the field and by piecing the various requests together determined we could address the majority of them with a large capability, that was also strategic in nature.
For example, when Sales comes and says we need a feature — you cannot say yes immediately, you have to understand the problem and see what all the potential solutions are. Then you will start to see patterns over time with requests. When you start seeing a few customers requesting a certain thing , that’s what you know it is important.
How do you filter requests from stakeholders?
There is always a constant tradeoff between time, cost and benefit.
For customers: We have a community (similar to UserVoice) where people log feature requests and I focus on the top upvoted requests.
For sales: Sales engineers are the conduit between sales and the product. One sales engineer supports a number of sales people.
We have an effective process where sales engineers log product gaps and they tie revenue to the product gaps in Salesforce.
For example, they can say the top 10 product gaps amount to 5 million dollars in revenue. I can pull a report from Salesforce and focus on those.
For customer support: I get copied on all relevant tickets to make sure I’ve a pulse on the customer, which are about 50 tickets a day. Of course, reading every single one is not possible but you can scan a few and get a constant gist of the customer pulse. Any urgent tickets go directly to engineering.
It’s not possible to read everything. You are trying to get a sense of patterns. You will have a hypothesis and then see quantitative data to back that up and you will figure out how to prioritize that feature.
Once we decide what’s important to focus on and get a sense of the business priorities, we then translate them to user stories or epics in JIRA. This is the point where we involve engineering and design as well to understand the implementation cost.
At this point we look at a few factors before we prioritize them in a sprint:
- We see if the customer is blocked: Can they work around the issue? If they are completely blocked and there is no product workaround then it’s bumped up.
- Impact of the issue: How many people are being affected by it?Is it affecting a core business process or is it a corner case process?
- Engineering estimation: How much effort will it take to solve? Is the Engineering cost significant or does something else need to be sacrificed?
The actual prioritization of what goes in what sprint happens in JIRA. I keep the backlog in prioritized order as well. JIRA reflects the actual working roadmap of the company.
How do you communicate the roadmap to the rest of the company?
There are two kinds of formal communication — one on the upcoming roadmap and the other post the release of the roadmap.
On the upcoming roadmap there are two groups we engage with:
- Mini product council: These are stakeholders related to my product group and we meet monthly to inform them of the features which are coming up.
- Exec product council: A monthly meeting held by our head of product, which brings executive alignment with the roadmap so executives can give feedback on it.
Keep in mind in the above meetings none of the features would be a “surprise” to anyone. It is important to go to the meeting with “strong opinions, weakly held” as to why the prioritization should be the way it is but being prepared to also take feedback.
Post the release of the features this is how we communicate them to the rest of the company:
- Powerpoint: For large features we have internal design decks that serve as the foundation for informing the rest of the company.
- Company wide release overview: Every release, we do a monthly solution overview which the company is invited to and the PM goes through all the features in that release.
- Documentation: Post the release, we also have documentation maintained by our team of document writers, who ensure that the customer facing documentation for the product is up-to-date.
- Exec Product council: This forum additionally serves as a place to discuss features post-release.
In conclusion, B2B product management is not linear. A product roadmap is speculating the future and anything can happen between now and the release of a feature. With so many variables at play, like with any forward-looking statement, one should make decisions based on present evidence and not on future suppositions.
