You're Thinking About Product Wrong
I spent years inside an engineering-heavy startup thinking about product wrong, or as charitable people would say, naively.
Our team suffered from what I call “the engineers’ fallacy,” which is an excessive focus on the thing you’re building. Our egos were invested in polishing the surface of our APIs, on making our code better and faster and more performant.
I understand why people do this: they’re focusing on something they can control, and that gets them out of the mess of human interactions and political decision-making, which is a major reason why some folks gravitate toward code and computers in the first place. It’s like the man in the parable who searches for his lost car keys under a street lamp, because that’s where the light is. If only life were so simple. Our view of product was something like this:
In our view, every product was a function with inputs and outputs. What we were optimizing for was giving people the best outputs we could (often based on what we wrongly imagined they needed). We were, you might say, “benefits agnostic”. (In part, I think this is because we had many kinds of users with fragmented needs and never reached true product-market fit.)
So our company was essentially a bunch of engineers thinking about the technical systems our team was building, and trusting leadership, including me, to give our product strategic direction to ensure that we met users’ needs.
To be clear, it’s perfectly fine for engineers to do that as long as their leaders give them the right guidance, but as I and others can tell you, that is often not the case. (Builder beware!)
Here’s the system we should have been thinking about:
The only system worth reasoning about, in fact, was the fused entity formed between users and our product. This point has been made many times by people smarter than me, including by authors like Kathy Sierra, who wrote “Badass: Making Users Awesome”; Clayton Christensen, who wrote about products’ Jobs to Be Done; and Steve Blank in his blog posts and books.
The only way to get a clear picture of this larger system, which I think of as a cyborg because it combines humans and software, is to talk to users. Get out of the building. Or at least onto a Zoom call. Ideally, you would shadow them for days on end, live in their office, and watch them perform the workflows that you think your product might affect.
And how do you do that with the right people? You find the ones who are already using your product, or who might possibly want to, and you convince them to speak with you repeatedly and at length. Those conversations involve a major time commitment on the part of your users or prospects, which is a challenge in itself.
This is why some of the best startups are founded by people solving their own problems, because they are willing to give essentially infinite time to understanding their own workflows and needs. Other great sources are friends and family members who care about you, or team mates and former colleagues who trust you, and whose problems you understand well already.
Less good but serviceable starting points are paid conversations through sites like User Interviews (one reason those are less good is because you have limited cash, and needing to pay for these conversations is in itself a sign that you are far from a visceral understanding of the problem. Paid conversations are more acceptable when you’re expanding into new markets after finding initial product-market fit).
What this approach elucidates is the goals your user hopes to achieve: What are the outputs expected of them?
And that in turn leads us to another sketch:
Your user is part of a larger system, which in turn expects things from them. That larger system may be their customers, their clients, or their employer (i.e. the sole customer of their labor). By the same token, if you are a freelancer, you could substitute yourself for the product, your client for the user, and your client’s employer for the larger system.
A useful question to ask in all these cases is: Who are my customer’s customers, and what do they want?
This kind of second-degree question is also helpful because, if you are building an innovative technology, you may be approached by corporate innovation labs and consulting shops who want to feature your technology.
And the answer to the question of what your customer's customers want, in that case, may be “Nothing.” Your customers might succeed by wringing a demo or integration out of you. That is, just because you have some first-degree customers asking for trials doesn’t mean you have folks with a hair-on-fire problem which they will pay recurrently over years to solve. I encourage you to find that out before you build too much for them; their incentive will be to get that integration.
Yes, information is expensive, and it takes time, effort, and the support of your users or prospects to build your mental models about these systems. But let me assure you, it does not take more time than building the wrong product for years based on false assumptions about the market!
Some founders stumble into these product-first fallacies due to traps in the language. For example, everyone talks about product: The news reports about “successful” products. Investors and media share information in a tech-first or product-first way, talking about how AI or LLMs or blockchain as though they existed ahistorically in the ether.
Even inside companies, there are roles with product in the title, and roles with customer in the title, and they are separate roles... (I remember hiring product managers and thinking to myself: “They must know how to do this, they’re product experts!” I was wrong.)
Every product manager is really an expert in the people the product is meant to serve, or they are nothing. That is, I was holding the wrong end of the stick, as was much of the world. All the people talking about product without context are looking under the street lamp rather than feeling their way out through a dark field of user interviews, which is both harder to do and talk about.
Very early-stage startups cannot afford to specialize so much that product and customer roles are separate, since most of them don’t have either. (Even more mature companies question this division, with companies like Snowflake abolishing customer success roles on the grounds that the only purpose of the whole company is customer success. See Frank Slootman’s excellent book Amp It Up for more details.)
While it is useful to create the best possible product that you can, that product only acquires meaning and utility when fused with a user, whom you must understand deeply in their own context if you are to build a product they’ll pay for. The only entity worth thinking about, as CEO or product manager or investor backing a company is this one, where the product and users join.
Indeed, understanding what your users need is the only way to start thinking about strategy as a tech startup; building the most-performant product is merely a tactic to carry that strategy out. And to quote Sun Tzu: “Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.”