Main illustration: Olenka Malarecka
A great partnership between product and sales needs to be based on shared definitions of success and an agreed upon process to collaborate.
Without these things, the relationship retreats to the magnetic stereotypes of both industries: Product teams think sales teams will do, say and sell anything to make money, while sales teams think product teams will build anything cool except things that actually make money. It’s not a good place to be.
Ingredients for success
First, for a product to truly be considered successful, among other things it has to be:
- Valuable – solve a real problem people are willing to pay for.
- Marketable – be attractive enough to differentiate itself from competitors.
- Adoptable – have sufficient table-stakes requirements for features such that the majority of the market can adopt it.
- Justifiable – demonstrate its value as being greater than its cost (time and money) to the customer.
However, a great product is more than something that “the market accepts”. There are other hard requirements in building a successful product business. The product must also be:
- Secure – features must be added thoughtfully so as to not create new attack vectors.
- Scalable – every new feature must work for your largest customers and future largest customers.
- Reliable – business critical software can’t have features with bugs that go unresolved for years.
- Usable – you can’t build features with no cohesive vision that need layers of solution consultants to walk every new customer through them.
- Sustainable – the footprint of the product can’t grow exponentially to accommodate every new feature request, which jeopardizes all of the above.
Product teams that don’t understand the first list will never connect with sales. Sales teams that don’t understand the second list will never connect with product.
“If your product team isn’t taking roadmap input from your sales team, you’re not listening to the potential market”
Second, sales and product need a way to collaborate on the product roadmap. Sales is usually the only team that has in-depth conversations with would-be customers who couldn’t proceed due to a product problem.
If your product team isn’t taking roadmap input from your sales team, you’re not listening to the potential market. You can go deeper in your current niche, but you’ll never expand out of it, nor will you move upmarket.
Solving customer problems
At Intercom we take inputs into the product roadmap written in the form of a “problem.” Each problem is an atomic unit that articulates why a deal can’t be completed. The problem has an abstract statement (“I can’t connect conversations in Intercom with my user record in my CRM”), a reason it’s a problem (“using Intercom would make my sales process too inefficient for SDRs who would have to copy and paste all day”) and then instance details (“I need to see sales conversations in the Hubspot CRM”).
In addition we capture things like:
- Stack rank
- Status – is it currently being worked on?
- Persona – who in the buying process speaks to this need?
- Segment – what customer group does this first occur in?
- Order of magnitude – often the gap between #1 and #2 in the list is substantial, as seen in this diagram
Feature requests by rank of problem and by size of problem – your second-ranked problem might be far less important to resolve than your top-ranked problem. Idea popularized by Ken Norton
All of this is refreshed at every roadmap session, and detailed discussions are had with sales as a new problem is tackled. It can be easy to let this list become your roadmap, and if you’re really lacking the table stakes features in the market, that might be the right choice.
But it’s important for both sales and product leadership to remember you can’t “table stakes” your way to a dominant market position. You need to differentiate. Faster horses will get you only so far. Your roadmap should have many other inputs, such as iterating recent launches, new to market innovations, and causes of customer churn. What changes and evolves is the weight of each input, depending on where the shared priorities are. A roadmap, at its core, is just a page of trade-offs, arguments and priorities.