Product Innovation beyond the “Fast Waterfall”

Andy Stinnes is a seasoned entrepreneur, leader, product builder, and innovator in B2B cloud applications. He advises startups and scaleups in all matters of strategy, go-to-market, and product.

Having worked for and with many B2B startups and scaleups over the years, I am always fascinated by how their product development process works – or doesn’t. I am often struck by how similar the issues are, irrespective of vintage and stage of the company.

Fast waterfall

Agile development has been around for a good twenty years now. I personally lived through its early adoption and the tricky transition from the old 12-18 month “waterfall” release cycle. Nowadays, agile is universally accepted as the gold standard. For development.

The biggest obstacle I encounter in many early stage SaaS companies is a lack of test automation and dev ops maturity. Being fast and scrappy, startups tend to give short shrift to test development until they win enough customers and achieve product-market-fit. Then a wave of customer-driven enhancement typically pushes the effort further out. At some point, like a company I met with recently, they find themselves approaching 10M in ARR with still only 10% test automation. Ouch!

The development process still follows an agile methodology, and they deploy to production fast and often. But due to the limitation in testing, they use that capability mostly for bug fixes and localized feature changes where the urgency is high and the risk is tolerable. For larger and more invasive changes, a much less frequent, often 3-4 times a year, release process is utilized that includes a full, manual regression testing period. I call that the “fast waterfall”.

Modern product discovery

While the back-end constraint of insufficient test automation is a real and formidable barrier, a far greater obstacle to a modern and truly agile product innovation process lies with product management: product discovery. 

Over the past two decades, just like agile for development, a similar rethinking has occurred for how SaaS companies discover what products to build and how to design the user experience. Gone are the days of feature-function building off a product roadmap, driven top-down by senior management and product leaders who are domain experts and supposedly know what customers need. That mindset has been replaced by design thinking and a relentless focus on market testing, early and often, with prototypes and all manner of experiments, to validate value, feasibility, usability, and business viability before committing to build and delivery. Design sprints, focus on user experience (UX), and going into production with minimum viable product (MVP) are all elements of that transition.

Old school Discovery

However, the on-the-ground reality in many B2B startups I see looks quite a bit different. Within the development process, things look good. The product manager (PM) is the product owner of the product team, consisting also of a designer and a handful developers, the product backlog is maintained in Jira and the scrum team works on a couple of those items every sprint. So far, so good. But when it comes to ideation, to discovering the market needs, how much value customers put on those, and if solving those is feasible and profitable business for the startup, things look decidedly backwards: old school discovery. 

Here are some of the telltales:

• PMs focus the majority of their time on the "what" not they "why".
• PMs work off a roadmap, often dominated by founders and customer needs
• PMs are overworked, the ratio of PM to Dev is still 1:8 or higher
• PMs spend little time with customers, mostly only to validate feature designs
• PMs were hired because of their domain knowledge 

These characteristics are particularly pronounced for companies marketing to larger enterprise customers. More on that later.

How did we get here?

If you ask the PMs, they know this is not the right model. At least the better ones do. So why are companies so stuck in this old school discovery model?

From the cases I see, I would summarize the root causes as follows:

1. Hiring too late: Founders are naturally the original PM. Early hiring is often focused on development and then go-to-market. Only by the time the initial product is in use by customers and the sales motion is beginning to track, do founders tend to hire PMs. By then there is already a lot of feature backlog coming in from customers and sales and from day 1 the PMs are playing catchup and are hard pressed to find time for discovery.
2. Insufficient capacity: Unlike salespeople or developers, who are seen as “productive”, PMs tend to be perceived as overhead. They don’t create leads or sell or develop code. Hence PM teams are small and kept at ratios whereby they can just about keep up feeding developers. However, the modern customer-focused and evidence-based discovery and ideation process is very resource-intensive. Even if they have the desire and right skills, many PMs drown in the daily pressure cooker of product-owner role to the dev teams. Discovery is the “strategic but not urgent” work that they never get to.
3. Hiring priorities: Domain knowledge is often still hiring priority number 1. Admittedly, a PM who knows the category and industry will come up the learning curve much faster and be more credible in front of customers. But that decision includes an unstated bias toward a PM “who knows what features the customer needs” vs a PM who knows how to find out what products can be successful in the market.

Enterprise SaaS: the law of small numbers

For SaaS companies focused on big enterprise customers, and additional challenge arises. Customer access. 

Modern evidence-based product discovery requires ample customer access. Whether it is observational (e.g. observing current behavior), qualitative (e.g. interviews), or quantitative (e.g. A/B testing) research, it all hinges on access to the right customer. As anyone who has worked as a PM in an Enterprise SaaS company will tell you, that can be quite challenging. Why? Because there are orders of magnitude fewer of your target customers and users out there, finding them is tricky, and, unless they are already a customer, getting them to spend time with you even harder.

A lot of the books on modern customer discovery and validation research were written with B2C consumer software in mind, where a representative set of users can easily be found and A/B testing across the existing thousands of users is straightforward. The closest in B2B would be SaaS vendors with horizontal solutions sold to large target markets (e.g. productivity apps). But what if you are making software for the construction industry and are trying to understand how project managers of large commercial building projects handle certain work tasks?

That is why enterprise PMs – even those who have the time and inclination – typically struggle to get much beyond a pronounced effort to speak to existing users and customers. Not ideal, as that conversation it is always within the context of the existing product and prone to selection bias. If you are not careful, the “innovators dilemma” is right around the corner.

Advice to founders

Agile development and a “fast waterfall” are not enough. Moving product discovery as close to a customer-focused, evidence-based process as your circumstances allow are an imperative for founders and SaaS leadership teams.

Keep the following in mind as you tackle this transition:

• Identify a “chief discovery officer” on the leadership team
• Ensure a top-down commitment and visibility at the exec level
• Invest in retraining existing PMs – there are plenty of great resources for that
• “Over hire” PM capacity relative to what you have historically been used to
• Hire PMs for customer focus and discovery process, not domain knowledge
• Instill a culture of “PM extroversion”; they need to talk to customers often
• Everyone in sales: PMs should be actively engaged in sales, demo the product
• Be flexible and realistic: find a mode that works in your company’s situation

It’s a journey that requires commitment and persistence. It will take time. And you might not achieve the ideal portrayed in the books you read. But it will be a lot better than what you do today and will greatly improve your product discovery and therefore delivery process in terms of effectiveness (building what the market actually needs) and efficiency (avoiding waste in ill-conceived products and features).