All of this is true. And yet, as we enter the late-morning of the era of the product-driven startup, it’s never been easier to automate your way to results. In fact, the quality of the product is almost secondary to the quality of the machine that builds, delivers, and improves the product.
You truly can build a successful product if you listen to four important sources.
The only problem is, these same four sources can also lead your startup to ruin.
A quick discussion of the evolution of the product-driven organisation
Software as a Service, two-sided marketplaces, subscription pricing models, eService, direct-to-consumer, and the concept of Minimum Viable — all of these phenomena owe their existence to the evolution of startups from sales-driven to product-driven organisations over the last decade or so.
But what does that mean, exactly?
It starts with a shift in company structure
At a strategic level, the change is from a structure that puts sales on one side and build on the other to a structure that accommodates the customer’s journey from their first discovery of the product to the end of their usage of the product.
At a tactical level, the shift has mostly manifested itself in the onset of the product role, from product marketing to product management to product engineering.
To make a long story short, product-driven companies use sales engineers and product marketers to bring product advancement closer to the customer, and they use product managers and product engineers to bring the customer input closer to the product.
This structural evolution allows the customer to have a bigger say in mandating what the company builds, which ends up being what the customer buys, which creates a virtuous cycle.
But can that cycle really be set on autopilot and become self-fulfilling?
Not entirely, but you can get close. Here are the four people you should be listening to (and the four situations in which you shouldn’t).
Customers
I’m not dropping any secrets here — always listen to your customers. So instead I’ll tell you how to do that and what can go wrong.
Structure the product side of your organisational framework so that you’re getting the right information and not noise.
Customer support is on the front line with the customer, but their job is to fix the customer’s problem, not fix or enhance the product.
Customer success is the role that works with the customer to understand their usage, interpret their problems, and deduce probable causes of friction from their usage patterns. Their job is to advocate for the customer, not make a better product.
Product managers create functional spec to address customer issues and needs as interpreted by the customer success team, with input and validation from customer support. Product managers work with the engineers to turn functional spec into features and enhancements.
That structure will get you to development of a customer-driven product. But here’s where it can go off the rails. There is a big difference between a product-driven organisation and a customer-driven product. They’re not mutually exclusive, but by no means are they the same thing.
Without getting too deep into the weeds, always remember that the customer is ultimately in it for themselves, not for your company or your product, no matter how loyal they become. This is not a bad thing, but you’re not trying to serve your most loyal customers, you’re trying to serve all your customers.
Your most loyal, most engaged, and most vocal customers are indeed the customers you should be listening to, but always remember they represent your best case scenario.
These customers are your bellwether, and any changes you make or direction you take to extend your product-market fit should come with as little expense as possible. Just keep in mind that you will do well by making your customers happier, but if you want to grow, you'll grow faster and bigger by making new happy customers.
The Market and the Industry
Your product team takes a reactive role in responding to your customers’ needs. But to get to new happy customers, your product team must also take a proactive role in identifying market trends and industry advancements that your company can capitalise on.
All markets evolve, and all industries advance. Being at the forefront of trends that stick and responding to advancements as they happen, or even before they happen, is what fuels market expansion.
Netflix didn’t invent streaming. It didn’t do streaming well out of the gate. But Netflix saw what everyone else didn’t see, or ignored, or denied: DVDs were dead. The most loyal, engaged, and vocal Netflix DVD customers hatedNetflix when it separated streaming from its DVD service.
Those customers were wrong.
This kind of thing doesn’t happen often, but that story crystalizes the need for experienced hands moulding the company and the product to meet customers’ needs as those needs change.
More often, the market mistake is made when the growth vectors become the sole driver for product development. This is where you get the gold rush of “nexts” — the next Amazon, the next Facebook, the next Zoom. This is also where you get “buts.”
We’re like Uber, but for kids
We’re like Spotify, but for podcasts
We’re like Yo, but for business
You end up with one of three things: A product nobody wants, a product nobody can make a profit on, or a product that gets crushed when Spotify decides to do podcasts.
The Technologists
Call it engineering, call it manufacturing, call it science or whatever it is that builds the product you’re selling. Your tech team should be chasing features and enhancements that no one has ever thought of — because those things are just now becoming possible.
That said, the wrong way to go here is to chase the classic solution in search of a problem. In other words, just because you can do something doesn’t mean you should.
Lately, this problem runs rampant in automation.
I’ve spent a career automating tasks, everything from washing cars to writing sports articles to fermenting beer. I’ve developed a pretty keen eye for bad automation, which is automation that takes a necessary element of choice out of the equation in order to automate it.
Automation must narrow down a series of choices to the single best, then take that path. When automation produces random or poor choices and puts them in front of the customer, it fails in a way that does more harm than good.
I get asked a lot for an example, and this is a clear one: You know how when you call a business and you get a series of choices based on what they think you’re calling for? Then you have to speak one of the choices aloud and the system may or may not understand you?
That’s bad automation.
The Money
This last one is also no secret — always build where the money is coming in, whether that’s what your board is telling you, what your investors are telling you, or what your biggest customers and customer prospects want.
You can’t go wrong here. But you can
A strategy I’ve adopted across my last few startups is to always listen with open ears when important outside influences have suggestions, and never say no, but be prepared to say not right now.
There are two types of constituents you have to satisfy. The customer is looking to maximise the value they get from your product, the outside influence is looking to maximise the return they get from your company. Both are necessary, but when the needs of one step on the needs of the other, it’s very difficult to recover.
If you test a customer-driven feature and the test shows that you will lose money every time the feature is implemented, you’d never do it. At least not before you solve the problem that’s causing the negative margin.
It’s the same on the other side. If the change you’re about to make to satisfy an outside influence is going to change your value equation, you need some hard evidence to show whether or not that value change is going to drive away existing business or prevent future business.
Always test first
In fact, a good overarching build strategy is to balance these four voices and look for conflicts. When one voice is calling for a change to your product, check in with the other three. This will not only prevent you from making some unforced errors, it will also help you prioritise by building the features and enhancements that satisfy all four sides the most.
This article was originally published on Medium by Joe Procopio
Joe Procopio is a multi-exit, multi-failure entrepreneur. In 2015, he sold Automated Insights to Vista Equity Partners. In 2013, he sold ExitEvent to Capitol Broadcasting. Before that, he built Intrepid Media, the first social network for writers. You can read more and sign up for his newsletter at www.joeprocopio.com
