Thinking Like Product

When did you last speak directly to a customer? How do you get user feedback? What’s your riskiest assumption about user behavior? How do you estimate the value of a feature before building it? How do you decide what not to build?

The Hardest Question Isn’t “Can We Build This?” It’s “Should We?” #

The session opened with a lightning talk, and one line in it reframed everything that followed.

There’s a kind of failure, the speaker argued, that looks like success: the thing ships, it’s technically clean, nobody’s mad and it still doesn’t matter. That’s not a delivery failure, they said. It’s a product thinking failure.

Most of us were trained to ask one question: can we build this? The talk pushed a sharper one: Should we build this and why?

What I watched unfold over the next hour was a room full of operators trying to redraw old lines for a world moving underneath them. These are my notes on where the conversation went.

Three Shifts That Change the Question #

The opening frame I kept coming back to was a set of three mental shifts the speaker laid out.

Features → Outcomes. Their example: when a stakeholder asks for “a dashboard with 14 charts,” the dashboard is the solution they’ve already imagined. The job is to hear the real request underneath I need to make a decision faster.

Users → Jobs. Stop asking who are my users? Ask what job is someone hiring this for, and what does success look like? The point being: people don’t want the tool, they want the outcome it produces.

Launch → Loop. Projects end; products iterate build, measure, learn, repeat. That third shift produced the line I underlined twice:

If your work has no feedback loop, it’s not a product. It’s a deliverable. And the reframe the speaker built the whole talk around:

Product thinking isn’t a role. It’s a lens. Before you estimate a ticket, ask what decision it unlocks. Before you write a spec, ask what success looks like at 2pm on a Tuesday. What struck me was the closing observation that the people who move fastest aren’t the best at execution. They figured out early which hill was worth climbing.

The Faster-Horse Problem #

When the group discussion opened up, discovery was the first place it got hard because, as several people pointed out, the data lies to you.

One participant working direct-to-consumer described the recurring frustration: ask people what they want and they tell you what they think you want to hear. Or, as someone else put it, they ask for a faster horse when the answer is a car.

The response that landed for me wasn’t a technique but a temperament. You have to give up the very thing that makes you a great engineer solving immediately and sit in the problem instead.

Two methods came up that I want to remember:

• Watch, don’t ask. One person described spending days just observing people use a product, cameras on the screen and the face, giving only outcomes to attempt. Their honest caveat: it told them how to optimize what existed, but nothing about what to build next.

• The reverse demo. Another participant flips the enterprise demo they have the prospect demo the product back to them, narrating out loud (a trick borrowed from industrial psychology). Their words stuck with me: it’s humbling, and it obliterates your assumptions. You watch someone hunt for a feature that doesn’t exist and realize you built the interface around a problem they weren’t solving.

A trap surfaced in that thread too: someone noted that smooth onboarding “teaching the user in two minutes” only proves you executed well if you already built the right thing. Good onboarding presupposes a correct product. It doesn’t prove one.

The Surgery Was Successful, but the Patient Is Dead #

The deepest current of the night, to my ear, was outcomes versus activity.

One participant put it as a line I scribbled down immediately: the surgery was successful, but the patient is dead. Every function can be busy, every bucket full of well-organized work, and the result still adds up to nothing. Their gut-check for exposing it: ask most product and engineering people how does the company actually make money and you get bizarre answers. It’s a simple question, they said, and the fact that crisp answers are rare tells you something.

The conclusion the room more or less arrived at was to work backwards:

Start at the outcome you’re driving, then ask what you need to build so the data feeds the loops that compound it.

Someone framed the difference cleanly starting at the beginning gives you motion, starting at the outcome gives you clarity.

What’s the Last Product You Killed? #

One participant shared a question they like to ask, and the answer it usually gets: “What’s the last product you killed?” met, more often than not, with a blank stare.

Most people have no answer, and the room agreed that’s the problem. Pareto runs the place roughly 20% of products drive 80% of revenue but a culture that keeps anything making even a few thousand dollars never cuts anything, and slowly drowns in its own catalog. Someone pointed out that even the most rigorous shops, the ones who write the press release before building, still shipped phones that went straight to the landfill.

The takeaway I noted: you have to learn to cut things far more aggressively than you build them.

Reimagining the PRD #

No artifact took more fire than the PRD.

The complaint, voiced more than once, was that too many PRDs are disguised functional requirements acceptance criteria dressed up as problem statements. A few people noted how much the economics have flipped: a spec that used to absorb a month is now a two-hour conversation dumped into a context document, deliberately implementation-agnostic, letting the model drive delivery.

But the sharpest point, made by one participant, wasn’t about speed:

The same PRD can unite product and engineering or separate them. It can be the table where both views meet, or the wall they throw work over. The difference is entirely in how it’s used.

The minimum standard someone proposed for the modern version: a functional spec, a data spec, and a visual spec. They were emphatic that the data spec is the one everyone forgets and the one that matters most, because without it you don’t know what you’re measuring or how to close the loop.

Maximum Value, or Minimum Lovable? #

One of the liveliest threads started when someone raised a pattern they’d been hearing: instead of iterating, go all in let AI prototype the whole thing up front and ship the maximum-value version in one shot.

The pushback was immediate, and came in two parts. First, from one participant: How confident are you that you even know what “maximum value” is? Second, and more practical signal. Bundle six features into one release, someone pointed out, and you’ve blown your own feedback loop. Something moved the numbers. Which one? You can’t tell.

The reframe the room preferred came from one person who’d clearly been sitting on it:

Minimum lovable. Past viable the version you’d actually enjoy using but well short of the Taj Mahal.

A participant described a model that threads it: product and engineering rapid-prototype together in real, throwaway code, iterating with the customer on the whole pipeline. First iteration is hot garbage, they said, and that’s fine only when the customer asks “Why can’t I have this now?” do you bring engineers in to harden and scale it.

The analogy that closed the thread was my favorite of the night: someone noted that rats and elephants run opposite reproductive strategies, and neither is confused about what it’s doing. Each is fit for its context. Companies are the same. The question isn’t which approach wins it’s whether AI now lets you lower the cost of discovery and buy more clarity.

When the Customer Is an Agent #

This is where the discussion got speculative.

The premise one participant offered reframed the rest for me: good context is good context. Whether you’re feeding a frontier agent or an empowered engineer, you’re doing the same job and a bad context layer hands you garbage either way.

Which raises who the document is even for. As someone walked through it: if no human ever reads the code, the PRD can be written for the agent as customer; the moment humans across the org need to align first, it can’t be.

The horizon a few people gestured at was customers splitting into human and agentic with broad agreement that SaaS won’t die so much as be forced to go headless or reinvent itself.

The Double-Edge #

The closing tension, raised toward the end, was that AI is dissolving the barrier between “engineer” and “everyone else.” Suddenly anyone can get to zero-to-one and, as several people noted, just as fast slide back to zero.

The vivid version came from one participant describing an expert who’d built something that felt finished and ready for customers, with no idea he was still in batting practice not even the first inning.

And the flip side was sharp. When everyone can build, someone observed, everyone can also expose a year’s roadmap sitting public for hours, a finance model leaking out. The phrase that got repeated: we’ve moved from knife fights to bazookas.

But the discussion grounded itself before it ended, and I think this is the right place to land. As one person put it: there’s a whole world outside Silicon Valley and downtown Austin where most people and most companies under a hundred simply won’t build their own stack.

The future is arriving unevenly. Product thinking is exactly what tells the difference.

The Real Question #

Strip away the org charts, the PRD formats, the build-vs-buy debates and what the night kept returning to was the question the lightning talk ended on, the one to ask before you open Jira, before you write the spec, before you touch the IDE:

What does the person who needs this actually need to do next?

Answer that honestly, the speaker argued, and most of the rest takes care of itself. Skip it, and you get the cleanest, best-executed product nobody needed.

Sitting in the room and writing it all down, that’s the line I left with. Product thinking isn’t a role, a title, or a phase of the process. It’s the discipline of knowing which hill is worth climbing and the humility to keep checking whether you’re still on it.

Suhas Rayapudi is founder and CEO of Baylish