Notes from the founder
There’s never been a better time to build. Everyone has been saying that for a while, and lately, with AI in the mix, it seems to be coming through a bullhorn.
Yes, I think it’s true. But there’s a part they leave out.
Coding stopped being the bottleneck this year, or at least generating code did. The ceiling moved, not the floor, and I don’t think engineers are going anywhere.
But the number of things that get built is about to go up and most of them will be built by small teams and by agents.
What hasn’t gotten any easier is the thing that has always been one of the hardest parts of building: knowing who you’re building for, what problems they have, and why they’ll care about your solution.
The same pain at every size of company
Over the spring and summer I ran discovery interviews with product teams, from seed-stage startups to mature companies like Adobe and Nike. I also mentor very early-stage founders. What I heard was the same problem at every size: understanding what customers need now, and how that’s changing.
A solo founder looking for product-market fit talks to customers every day and keeps the notes in their head or scattered across Google Docs, Granola, and Notion. Making sense of it all while building the product is difficult, but doable. But what happens when you add a contractor, a first hire or two, a bunch of agents, and maybe even a different type of customer segment?
Probably chaos.
A mature company has the opposite problem: signal versus noise. Thousands or millions of customers, several different kinds of them, and more evidence than any one person can read: interviews, surveys, support tickets, call notes, Slack threads, analytics. The job becomes making sense of all of it, prioritizing the sources, and even just knowing what to trust.
In nearly every interview I conducted, the new AI-assisted workaround took a similar shape: a product manager pastes what they have into an LLM, which is only ever part of the picture; tries to supply the missing context about the problem and the customer in the prompt; and then doesn’t fully trust what comes back.
They then spend the time chasing down the sources as best they can. One of them put it exactly: “I have to cross-verify everything.”
PMs are on the front line of this. There’s a decision to make because the team hit a blocker. The roadmap meeting is at 11. The quarterly readout to leadership is tomorrow. The customer evidence exists somewhere, but hardly anybody can get the full picture when it’s go-time and it matters.
Even knowing what you don’t know about your customers, your company’s knowledge gap, is hard.
The Sonos story
I’m a Sonos fanboy and a longtime customer. I own most of what they make, I recommend them whenever I get the chance, and I lived in Santa Barbara, where they’re headquartered, for several years.
In May 2024, Sonos shipped an app redesign that had been tested with some of its customers and not others. Longtime owners lost features they used every day, and they basically revolted.
The cost, by the company’s own accounting, ran to tens of millions in remediation, two delayed product launches, and at least a hundred million dollars in revenue. Eventually, it also cost the CEO his job.
Two years later, the current CEO described the fix in his own words: hundreds of hours watching real customers use the app, “longtime owners and brand new ones alike.”
To be clear, this isn’t a Sonos problem. Sonos is the one that happened to play out in public. And it wasn’t a research failure. Sonos knew those customers. The evidence existed, but it presumably wasn’t in the room when the decisions got made.
It isn’t rare, either. Even Unity, the game-engine maker, priced a fee as if every developer were the same developer, and its president’s apology ten days later said the whole thing in one sentence: “We should have spoken with more of you.” More recently, Notion’s CEO has said the company built its first versions for the customer it knew and “learned that actually most people just don’t care.”
Three companies with great products, real research teams, and real data. Three major decisions made without the customer in the room.
Researchers did this by hand. AI lets us scale it.
I spent two decades leading research and design in enterprise SaaS, live-service games, and connected fitness. The work I’m proudest of wasn’t a study; it was getting what customers said in front of the people deciding what to build, at the moment they were deciding.
Doing that well is a set of judgments a good researcher makes without naming them: which evidence is credible, which sources count for more, what has gone stale, what a customer did versus what they said.
And the segments were never static. Customers change, companies add new kinds of customers with new products, and someone had to keep all of it alive, project by project, with the evidence scattered across tools and, mostly, across people’s heads.
Most of the time, that judgment never made it to the Tuesday roadmap meeting. A decision gets made on gut, or on someone half-remembering a support ticket or customer feedback session. Someone else then remembers something different, but the CEO says we’re doing this anyway.
You’d be surprised how often I heard that the product team simply wants the evidence to push back.
But AI can scale that judgment now. Not replace it; scale it, so it runs on every question, every time, instead of only when a researcher happens to be in the room.
Product judgment and taste aren’t a vibe
If anyone can ship working software these days, then shipping isn’t the edge. When building gets cheap, deciding is what’s left, and deciding well comes down to customer understanding, product judgment, and taste.
Teams know it. In Lenny Rachitsky’s December 2025 survey of 1,750 product managers, under five percent said research is their primary use of AI today. Nearly a third want it to be. That’s the largest gap of any PM task.
What Arktyp does
Arktyp builds a composite customer you can ask for each of your customer segments, from the evidence your company already has. You ask it a question the way you’d ask a colleague. It answers in your customers’ own words, with the source behind every line. When the evidence runs out, it says so, and that gap becomes the next thing your team goes to learn. When two segments disagree, it tells you they disagree instead of averaging them into a customer who doesn’t exist.
Builders need this context. So do builders working with agents.
Nothing in the stack today puts the customer in the room: not for the PM, the designer, or the engineer. And those roles are blurring. PMs are designing, designers are shipping, and engineers orchestrating agents need more product context than ever. The one thing none of them has is the customer.
Ask how your customers think, feel, and act. Ask Arktyp.
Marc
P.S. If you run a product team with more than one kind of customer and would like to pilot the beta, I’d like to hear from you.