Product at a startup

Doing product at an early stage startup is fundamentally different from doing it post-PMF, and even more different from a consolidated company. A few things make it unique.

First, you're default dead. Everything you do is in a race against time. No time for long discovery cycles, deep ideation, market research marathons, or multi-customer prototype testing. You need answers fast.

Second, you lack enough data. You're not producing much of it. At any stage of a company, having ultra high-confidence in decisions purely based on data is tricky. At early stage, it's nearly impossible. You have to act with conviction on incomplete information.

Third, it's not your only job. Even if your title is "Product Something," you probably have a mountain of other work. If you're a founder, you have a mountain range. You need to be lean with your approach to product.

Most product advice is written for established teams with resources, time, and data. This isn't that. This is for founders and early-stage product people who have to do product while doing everything else.

I think about this often—how to do product well when you're operating under these constraints. So I'm breaking this down into four core ideas that have shaped how we approach it at Querio: User Focus, Problem First, Simplicity & Constraints, and Speed & Iteration. The goal is to give clarity on how to actually do this at your stage—not theory, but the tactical moves that matter.

Continuous Discovery

Stay connected to your users and never stop doing discovery.

I’m going to assume that you’re talking to your users every single week. If you’re not, please fix that. And when I say users, I mean actual users—people who are paying for and using your product. Not prospects in your sales funnel. Prospects will give you nice ideas too, and you can learn about the market through them, but they're looking at a demo. They haven't actually experienced using it. That's a fundamentally different conversation that while valuable, should naturally carry less weight and I’ll leave for another time.

The hard part isn't talking to users—it's resisting the urge to jump into helping mode and forgetting to do discovery. You end up getting very specific with them about how to get the most value out of the product, so you shift into support/success mode and stop learning. I'm not arguing against helping your users get value. Just remember that while you're doing that, you can also learn a lot.

How to actually do discovery in those conversations:

When you're talking to users, don’t bring feature ideas up and instead talk about their life with a sprinkle of your product fits in. Ask them what they do right now to solve the problem. What did they do last week when this came up? Not "would you ever..." or "do you usually..." — specific past behavior beats opinions about the future every time.

Here's the trap: if you bring a feature idea up, they'll try to be helpful and nice. They'll compliment you. They'll say "I'd definitely use that" or "that sounds interesting." That's noise. You're looking for specificity. Ask "when was the last time this happened?" and "how did you handle it?”

Understand the job, don’t even mention the feature. Your product is being hired to do a job in their life. That job has functional dimensions (what task needs doing), social dimensions (how it makes them look), and emotional dimensions (how it makes them feel). It also has circumstances—when it arises, why it matters at that moment, what else they could do instead. Nail the job, and the solution becomes obvious. Miss the job, and you're building for yourself.

Don't mistake user opinions for user behavior though. Users will tell you what they think you want to hear. They'll ask for features that feel safe, that optimize for the status quo. Listen for the job they're trying to do, not the solution they're proposing. Sometimes users ask you not to do something because they haven't imagined a better way yet. Your job is to understand the underlying job, not execute every feature request. The distinction matters.

Don't fall in love with the first solution that comes to mind. Fall in love with the problem. The moment you start describing what you want to build, the conversation stops being discovery and starts being a pitch. Your user switches modes to being polite. You get false positives. You waste time. Instead, focus on understanding the context deeply. Ask questions that could actually destroy your assumptions, not confirm them.

Problem First

Start with the problem and stick to the problem, not the feature.

This is a pattern we all fall into, all the time. You see a problem and very quickly think of a feature that could solve it. You start thinking about the feature and inevitably get married to the feature itself. That slowly creates tunnel vision and gets you to naturally forget about the clear problem you were trying to solve in the first place. Most times you end up building a feature that might solve the problem, but you never really gave yourself nor your team the space to think of other features that could potentially be simpler and more effective at solving the problem.

You won't have enough data to be certain. You're going to make calls with incomplete information. That's the constraint. Write down what you think the problem is, talk to users about it, and then make a judgment call. Your intuition matters here—you've been paying attention, you've talked to users, you've seen patterns. But intuition without data is just gut feeling. Data without intuition is just noise. You need both. The earlier stage you are, the more you lean on intuition. But ground it in what you've heard from users, not what you think is cool.

Write the problem down first. What are users trying to do? Where is your product failing them? Why does this matter to them? These three questions force you to articulate the problem before you jump to solutions. If you can't answer them clearly, you don't understand the problem well enough to solve it.

Start from the customer's reality, not your solution. Write things down as pairs: problem statement + job-to-be-done. The problem statement is what they're struggling with. The job-to-be-done is the outcome they're actually trying to achieve. Starting from their reality (outside) and working inward to your product (inside) keeps you focused on solving real problems instead of building features you think are cool. Once you understand both the problem and the job, the solutions become clearer.

Organize your potential roadmap items around problems, not features. When you list problems first, solutions naturally become afterthoughts. This is the right order. You'll end up with multiple potential solutions for each problem, which lets you compare them and pick the simplest one that actually solves it. If you start with the feature, you never get to that comparison—you just build the first thing that came to mind.

Outcomes over outputs. Focus on the outcome the user wants to achieve, not the output (the feature itself). This distinction matters because multiple features can deliver the same outcome. If you're fixated on a specific feature, you miss simpler paths. If you're fixated on the outcome, you stay flexible.

Simple and Constrained Solutions

Identifying simple, constrained solutions involves clearly defining the problem, setting boundaries, and structuring solutions like a user manual to stay focused.

Set the boundaries. Write down the problem you're solving, state what users are trying to do and where they fail, and why this is important to them. Set an appetite—define how much time you're willing to invest on solving this particular problem. Couple days? One week? Two weeks? The appetite forces you to make trade-offs. It forces you to pick the simplest solution, not the most complete one. Without appetite, you'll keep adding and iterating forever.

Rough out the elements. Write out, breadboard, sketch what you want to build to solve that problem. Give yourself space to attempt multiple versions and be critical as you're writing this down. This is not about pixel-perfect design or final architecture—it's about exploring the shape of the solution. Leave room for designers and engineers to do their job. Don't be ultra specific about UI/UX or which tech to use. You're constraining the problem and the outcome, not the implementation.

Structure your solution clearly. Write it more like a user manual, not like a novel. Organize by actual product components—break it down by the parts that make up the feature (both visible and invisible). For each component specify: what it is and its purpose, how a user will interact with it, what options or controls they have, different behaviors in different scenarios, and anything that happens behind the scenes that matters. Include both user-facing and system components. UI elements and their interactions, rough data models and storage, background processes and logic, integration points with existing features. Make sure you write down how you're going to measure things after release and include that as part of your scope. You need to know if the feature is actually solving the problem.

Address risks and rabbit holes. Look for them explicitly. What could go wrong? What could take forever? Clearly define everything you're NOT building. Be explicit—if you thought about it, declare if it's in or out. Include related features that could creep in. The longer your "out of scope" list, the better your scoping is.

Discuss it with your team. As you're writing all of this down, talk it through with your team. They'll spot risks you missed. They'll find simpler solutions. They'll tell you what's easy and what's hard. Incorporate that feedback and refine the boundaries and elements. This is collaboration, not hand-off.

Speed & Iteration

Ship fast and small, use that to measure and learn. Rinse and repeat.

Build and iterate rapidly with your customers rather than going down planning and discovery rabbit holes. Let me break it to you, as much as you like to think you're Steve Jobs and you simply "understand it", you don't. The world and people are too unpredictable, you'll get some things right and most things wrong. The best way to find out is by shipping, not by thinking.

Small features that try to solve problems are the learning itself. You don't need elaborate prototypes (yeah this is now a thing) or polished prototypes before you ship. You need working features that attempt to solve the problem. Ship them to real users. Measure what happens, which includes talking to them. You'll learn more in a week of real usage than in a month of planning. The feature you ship won't be perfect. It might not even be the right solution. But it's data. Real behavior beats all your assumptions.

Fixed time, variable scope. You shaped it with an appetite—stick to that appetite. If you're running out of time and haven't shipped yet, cut scope. Cut polish. Cut edge cases. Ship the core. Ship something that solves the problem in its simplest form. You can always iterate and add more. You can't learn anything from work that never ships.

But don't ship just to ship. Speed matters, but direction matters more. You can iterate fast on the wrong problem and never get anywhere. That's why the first three sections matter—User Focus, Problem First, and Simplicity & Constraints aren't slowing you down, they're pointing you in the right direction. Speed without direction is just noise. ** Build-Measure-Learn. The ultimate Lean Startup loop. Ship the feature. Measure how users interact with it through quantitative and qualitative data. Do they use it? How are they using it? What problems does it create? Then learn—adjust, iterate, or move on. This cycle should repeat constantly. Weekly if possible. Every cycle teaches you something about what users actually need versus what you thought they needed.

Wrapping Up

You probably noticed that most sections start with a bolded sentence. They're meant to distill each idea into something clear and actionable. Here's all of them together.

User Focus

• Stay connected to your users and never stop doing discovery.

• Talk to your users about their life, not your feature ideas.

• Understand the job, don't mention the feature.

• Don't fall in love with the first solution that comes to mind.

Problem First

• Start with the problem and stick to the problem, not the feature.

• Write the problem down first.

• Start from the customer's reality, not your solution.

• Organize your roadmap around problems, not features.

• Outcomes over outputs.

Simplicity & Constraints

• Set the boundaries.

• Rough out the elements.

• Structure your solution clearly.

• Address risks and rabbit holes.

• Discuss it with your team.

Speed & Iteration

• Ship fast and small, use that to measure and learn.

• Small features that solve problems are the learning itself.

• Fixed time, variable scope.

• Build-Measure-Learn.

Each of these has depth—tools, strategies, frameworks to actually execute on. I'll probably write more about each in the near future.

Further Reading

These ideas didn't come out of nowhere. I've borrowed heavily from other product leaders who've shaped how I think about this. You can read these books if you want to go deeper if you want to dig in.

In no particular order:

• The Mom Test by Rob Fitzpatrick — How to talk to customers without biasing them

• Continuous Discovery Habits by Teresa Torres — Systems for making customer conversations a keystone habit

• Jobs-to-be-Done by Clayton Christensen — Understanding what job users are actually hiring your product to do

• Lean Product Playbook by Dan Olsen — A 6-step process for trying to achieve product-market fit

• Shape Up by Ryan Singer — How to scope work with appetite and ship with constraints

• The Lean Startup by Eric Ries — Build-Measure-Learn cycles and validated learning