3 minute read / Jun 10, 2019 /
Why Product Innovation Slows After the Series A
You’ve found product market fit. You’ve hired a team, including some managers. Your initial, small customer base is very happy. You’ve discovered an initial channel of customer acquisition that’s working. You’ve raised a meaningful round of capital. And then, right then, product innovation decelerates to zero.
The fast pace that characterized the past 12-18 months, when you would germinate an idea and write the code in less than a few days, has evaporated. Suddenly, the product and engineering teams are bogged down. Every innovation requires a Herculean effort to achieve.
Why? Why does this fact pattern evolve in many software companies? Here are the most common reasons I’ve seen.
First, technical debt. The freewheeling, hedonistic days of idea to instantiation in an instant are over. They’ve left you with the hangover of technical debt.
Architectural issues arise that the team didn’t anticipate when you were building features for a single customer or isolated use case. Now, there’s a growing customer base and more complex integrations. It’s time to shore up the initial infrastructure with production ready code. This happens at nearly every company, even Google. Few people are as motivated to refactor code as write new features. Combine technical debt with demoralized people and you get molasses every time.
Second, the founder/CEO’s once singular focus on product is no longer possible. Rewind a year ago, when 90% of their time was spent on product: finding product market fit, understanding customer needs, translating that into a vision and mocks to be coded.
Today, the demands on the CEO’s time have exploded manifold. Fundraising, recruiting, press, hiring, managing, board meetings; the task count and diversity has exploded. Instead of focusing 90% on product, they may have 15% or 20%. Without someone driving the product roadmap, product innovation decelerates.
Third, inertia. As your customer base grows, the product can’t move as quickly as you’d like because each iteration requires existing customer education. Even minor UI tweaks spike inbound customer support queries, which cost real money.
Fourth, testing. There’s a colloquialism for a collection of testing software within the quality assurance world: harness. The idea is to harness the furious efforts of the thoroughbred engineering team into a smooth release process that ensures few errors for customers in production. At this stage, the mot juste isn’t a harness, but a yoke, a heavy wooden cross beam braced across the shoulders of oxen.
Because just as the engineering team has accrued technical debt, so has quality assurance. Few companies have invested the effort during the crusade for product market fit to develop a robust testing suite. But as the business scales, testing becomes another key part of scaling infrastructure that requires significant investment, without any user-facing advances.
Most of these issues cannot be countered. Developing tests before product market fit isn’t worthwhile. You might anticipate inertia, but you won’t be able to meaningfully change customer behavior; we all habituate to software as we learn it.
But startups can focus on these areas when they arise by prioritizing great quality assurance, creating transition plans for existing customers, and finding a way for someone in the organization to run product nearly full time again; either by hiring someone and delegating that responsibility, or by delegating the other parts of the CEO job and focusing on product.