Does winning your next customer feel harder, when R&D ought to be making it easier? If you’re like many startups, the root cause is your sales-led product development.
Being sales-led is a necessary step in the evolution of your business. You’ve burned through seed capital, proven the core technology works, and gained happy customers paying real money for value – but every win seems to come at the cost of “just a few little feature commitments…”
During early stages of growth, it’s common and even advisable to prioritize immediate customer needs over long-term product strategy. The focus is necessarily on landing the next logo, even if that means deferring your strategic vision – and let’s be honest, you aren’t totally clear yet about what your market actually looks like.
Plus, you need the feedback (not to mention the revenue!) – and without the crucible of actual customer implementations, that strategic roadmap is just a theory.
However, when this sales-driven mindset persists for too long, product/market fit gets further away, not closer. Building out your capabilities and compatibilities in the order your prospects arrived won’t help you be a better fit for the broader market – and when sales-driven feature work represents the majority of your engineering effort, your product risks becoming blurry and incoherent.
For example, imagine you’ve built a product that queries relational databases. You can reach a lot of the market just by supporting postgres and MySQL, and most of the rest of it by supporting SQL server. A massive enterprise wants to become a customer, but they’re running Qbole. You’ll support Qbole for them, right? How hard can it be?
Suddenly, you’ve backed into supporting Hive, but your only test environment is this one customer – so your coverage is spotty, your documentation is full of exceptions, and you’re constantly worrying that your customer will upgrade and break your fragile integration. Oh, and now your account execs tell prospects “Of course we support Qbole!” and your sales engineers keep making that face, you know the one.
A little later, your query product is getting further into the business side and a prospect asks if you can do more than query data – can you write changes back to the database? That would be really convenient for this one operational use case they’ve got, where sales can correct deal forecasts in-situ. Sure, this breaks a core tenet of analytics systems (modifying data outside the transactional system) but it would open up a new use case – do you want to go there? Will you have to, in order to land this client? How much support are you going to put into this new product direction?
The examples are endless. If you’ve been in product for any length of time, you have your own story you’re thinking of right now. In aggregate, here’s what typically happens:
1. Inconsistent Feature Maturity: Some features are highly robust, capable of handling a variety of scenarios, while others remain shallow, lacking the depth of support expected by users.
2. Limited Use Case Portability: Features built for specific customers don’t work reliably in other scenarios, or aren’t relevant to the majority of new prospects, making qualification harder and cases studies less impactful.
3. Pre-Sales Challenges: Your pre-sales engineers struggle to show the product can support the needs of new prospects, or constantly hack around shortcomings in POCs. The features you developed in response to customer requests add to the complexity of your product but provide little competitive value or differentiation.
4. Technical Debt and Architectural Weaknesses: Least-cost feature implementations often lead to negative architectural tradeoffs, resulting in inter-module dependencies and technical debt. Over time, this slows down development velocity and blocks innovation.
5. Market Confusion: As your product becomes a patchwork of features with no clear overarching vision, your go-to-market teams will find it increasingly difficult to articulate who should use your product, what problems it solves, or what use cases it excels at.
6. Sales Bottlenecks: Your sales velocity is constrained by your engineering team’s capacity to develop new features. You will find yourself unable to close more deals simply because you lack the resources to meet the feature demands of new prospects.
7. Diminishing Return on Equity: As too much of your R&D budget is spent on serving the narrow needs of a few customers, your business begins to resemble a professional services shop rather than an independent software vendor. This erodes return on equity and stunts growth.
The Cure: Transitioning to Market-Driven Thinking
To avoid these pitfalls, a shift towards market-driven thinking is essential. Here’s how to do it:
Focus on Market Segmentation: For each new feature or capability, consider what other customers you could land with the same implementation. Assess whether this segment is addressable by your current technology and go-to-market team before proceeding.
Develop a Differentiation Thesis: Create a clear thesis on why a prospect should choose your product over building a solution themselves or opting for a competitor. Identify your core competencies and competitive differentiators, and build features that leverage and enhance these strengths.
Demand a Business Case for New Investments: Insist on a thorough business case from your product managers for each new product investment. Determine who will buy it, how you will market it, and whether it will attract new customers or expand existing ones. Incorporate both go-to-market (GTM) and technical reviews in your evaluation process.
Practice Saying ‘No’ to Feature Requests: Feature requests tied to specific deals should be the exception, not the rule. This is crucial whether you’re selling to SMBs, midmarket, or enterprise customers. If every deal requires new development work, it becomes impossible to maintain, let alone improve, your margins while scaling.
Allocate Limited Resources for Deal-Driven Work: Reserve no more than 10% of your development resources for customer-driven features, and assign a dedicated team to this category of work. This allows you to accommodate some customer-specific needs without derailing your overall product strategy. Ensure that the scope of these projects remains limited to prevent a single customer dominating this pipeline.
Separate Product Management from Engineering: In sales-driven companies, product management often reports to Eng leadership, and serves primarily as an intermediary between customers and developers. However, for market analysis and product vision to thrive, product management must be independent of engineering leadership, so that the natural tension between a market vision and a technical vision can lead to an efficient product.
Eliminate One-Off Features and Transition Oddball Customers: Where possible, shut down one-off features or use cases that were developed to secure early deals but have little appeal in the broader market. This may not be feasible for capabilities used by actively growing customers, but reducing unnecessary complexity will streamline your product. And wherever possible, help poor-fit or off-strategy customers transition to other solutions, as their revenue rarely makes up for the opportunity cost of servicing their needs.
Indicators of a Successful Transition
As you shift from sales-driven to market-driven thinking, several positive changes should become apparent:
Increased Customer Independence: A growing number of new customers successfully implement your solution with minimal need for new features or extensive technical support.
Organic Lead Generation: New business wins with prospects that came inbound, rather than in response to outbound sales activities.
Homogeneous Customer Profiles: Your prospects increasingly resemble each other, sharing similar architectures, platforms, technologies, and challenges.
Improved Roadmap Execution: You’ll deliver more of your strategic product roadmap on time, with fewer disruptions to your backlog.
Clearer Value Proposition: The problems your product solves become increasingly obvious and clear, making it easier to communicate your value proposition to potential customers.
Strategic Sales Conversations: Your sales team spends more time discussing the business impact of your solution with decision-makers, and less time delving into technical details with implementation teams. Sales engineers can service more accounts at a time, and focus primarily on big, high-value deals.
Timing is Everything
Timing your transition from a sales-driven to a market-driven approach is critical for the healthy growth of B2B products. Shift too early, and you risk building features without sufficient customer feedback. Wait too long, and your product will morph into a disjointed, incoherent platform. However, with the right timing, you can capitalize on early successes and propel your product toward a strong product-market fit, ensuring long-term success and scalability.
Reality-Based Product Management 