Strategy to Launch: How to Prioritize Features and Build a B2B/Enterprise SaaS Product
Creating a replicable process using popular frameworks for B2B products.
In this write-up, I’ll present a methodology I’ve used in the past to take a product from concept to commercialization (idea to execution) within a B2B/Enterprise context. This approach combines various standard prioritization frameworks.
Strategy
Start at the highest level. What is the goal of the organization? It should be something along the lines “Deliver to Customer segment X, value Y with the key outcome being growth in Z”. For a start-up in the Mobility space, it would look like this: “Deliver to OEM and Fleet customers, the ability to launch and run various revenue-generating businesses (Carsharing, Ridesharing, Scooter sharing) with the key outcome for our company being growth in the number of vehicles on our platform.”
When I joined the Ridesharing team at my present employer in 2018, I inherited a product that was firmly focused on the campus segment. My 1st task was to identify where to take the product. We decided the direction to take the product was Commercial EV ridesharing with the focus market being India. The rationale for this decision is beautifully developed by using the DIBB (Data, Insights, Beliefs, Bets) framework. See below
You may find yourself with more bets than resources. Stack-rank these bets in descending order based on the potential to deliver the key outcome for the organization and make your pick, starting from the top, based on available resources. The bet in Fig 1 above was one amongst many across multiple product lines that the organization considered and subsequently my team helped deliver it. Market conditions are subject to change and had we been looking at this data in a Covid world, this bet would not have made it.
Execution
Roadmap & feature prioratization
Once the Strategy has been developed, each team will have their mission (bet). Each of these bets would ideally be medium to long-term projects that may take 1–2 years to play out. My team’s goal of launching commercial ride-hailing services in India was easily a 6-month project to launch and possibly up to 12–18 months to assess product-market fit for.
Now, how does a team execute a bet? In 3 phases I’d like to opine
Launch Phase (MVP)
Always have a customer to launch with is another way of saying never build without a customer (for Enterprise like products). In the launch phase, your feature list will consist of a Minimum Viable set of features that you and the customer have agreed upon. The feature set for launch (MVP) should be the bare minimum feature set required to address the problem statement. For e.g. when we launched Ridehailing in India, we needed to address our feature set gap by building the following [New] features shown in Fig 2.
Stabilize Phase
As soon as you launch, you’re in the stabilize phase. This isn’t really a formal phase, but one you’d do better if you plan for. You probably have some commitments to the customer as part of the contract that the team is already looking to start building on, but once the rubber hits the road, all that will change. In this phase, you will be looking to fix and stabilize the features that have already been deployed and the customer will come to realize that many of the features that were on their near-term wish list aren’t that important anymore. While you focus on fixing your bugs, they will focus on getting their operations running smoothly.
Growth Phase
Once you and the customer have stabilized the product/service, you’re now getting market insights. This means you’ve entered the growth phase where you’re looking at what features to build out for growing the customer’s business. Ideally, by this time your sales team has brought you other prospects in the same segment to launch and you’ll now need to start balancing growth features for the customers already launched with any custom features that any new launch brings to the table (and there always are some). I have found the RICE (Reach, Impact, Confidence, Effort) framework to be useful for feature prioritization once we have a baseline product to build on. Here is how we thought of it from a Ridehailing standpoint once we’d launched our first two customers in India.
Some of the features in the list above like — Corporate rides and PIN-based dispatch at airports — allowed our customers to compete and grow ridership with 0ut marketing spend. Allowing users to pay by cash in a primary cash economy such as India was a must-have and Electric charge-based dispatch was part of our Strategic goal that allowed us to win new deals (and thereby indirectly more reach).
Sprint planning
In an ideal world you can just go down the list you have in your roadmap from sprint to sprint without any disruptions. But that’s never the case. Here are some general rules of thumb that I follow when planning for a sprint
- Always look to finish off a large feature prior to pulling in another large epic. Hence prioritize feature tickets that can get the feature complete and out the door
- No point starting work on a large feature when you have very few resources to focus on it in a specific sprint. Better wait for the next sprint and make a good dent in it
- Always keep some bandwidth for bugs. I’d like to say 30%. From time to time pause for a sprint after you’ve pushed out a few mighty features in consecutive sprints. Take stock and exclusively fix bugs
Multi-customer multi-product feature prioritization framework->
The roadmap and prioritization framework presented in this article is a very simple single product for a single customer approach. You will typically be balancing multiple customers, and maybe even multiple products. In the link below, I’ve presented how to ->
https://krishnansangs.medium.com/feature-prioritization-in-enterprise-saas-b7e20a1fcb1f
Sources
Dibb framework ->https://blog.crisp.se/2016/06/08/henrikkniberg/spotify-rhythm
Rice framework-> https://roadmunk.com/guides/product-prioritization-techniques-product-managers/
