I work with quite a few early-stage companies (<=10 employees), and they all seem to have the exact same problem.
Or, more accurately, all their problems are just different flavors of the same thing. Moat building, feature prioritization, pricing model design, initial GTM motions, or product strategy. All. The. Same.
These founders come to me frazzled because they don’t know how to make product decisions when practically everything is up for grabs. It makes sense: for most of your pre-startup life, you have foundational assumptions, constraints, and pre-made decisions. The job at BigCo (and even MediumCo) is just figuring out ε+1 over and over until you quit or die. Now, in startup land, you make thousands of decisions in rapid succession, with no solid ground, because committing to any single decision could kill your company.
These teams inevitably try some “startup-centric” process like Design Sprints, spend a few days decimating the local sticky note population, abandon it all as too heavy/awkward, and return to making every decision on gut instinct alone. Err, sorry, did I say gut instinct? I meant to say “taste,” yeah, “taste,” that’s the socially acceptable word for it now, right?
This dilemma comes from a false dichotomy: you can either have rigor or speed. BigCo has the former, startups have the latter, and founders assume the two are mutually exclusive. So they throw out the entire PM/UXR playbook, apparently convinced that customer research and seventeen steering committees come as a package deal.
I am here to say: this is why you are stuck. Instead of turning your back on established product development practices, you can embrace traditional methods while keeping startup speed and agility. The very tools that made BigCo life seem hellish and slow can help you build your dream company and a successful product!
In this post, I will share the steps I apply when starting a new venture. I’ve used this process about five times: at companies I bootstrapped, startups I joined, and portfolio companies I advised. It’s the product of two decades studying under more experienced product leaders and stealing their best ideas. I’ve deliberately left out anything that seemed to rely more on luck, context, or uniquely talented superstars, along with any processes where the ROI didn’t hold up in retrospect. I won’t claim this is The One True Way to do things, but with two successful exits under my belt, I’m willing to say “it sorta works.”
How to Read This Post
This is meant to be a sort of reference handbook of techniques—grouped into three categories: Understand Your Customers, Define the Product, Measure and Steer. These techniques work at all scales—from solo founder to huge enterprise—and can be applied upfront or as needed, with time investment varying based on how much depth or detail you need. I won’t define each one in detail (there are better sources, and doing it Exactly Right isn’t the point; vibe it up), but I’ll explain what I do, why I do it, and any hot tips I’ve picked up along the way.
The sections and methods are roughly in order; if you go top to bottom, it roughly lines up with going from “I have an idea” to “I have a product and am making money with it.” IF YOU ATTEMPT TO DO THESE OUT OF ORDER YOU WILL PERISH, I won’t tell—I’m a sign, not a cop.
Do not outsource these activities to an agent or an LLM of any kind. The whole point is the thinking you do along the way, which builds a rich intuition for how your customers and product domain really work, akin to Peter Naur’s Programming as Theory Building. Any actual writing and artifacts produced are secondary.
Understand Your Customers
Before you decide what to build, you need to understand who you’re building it for, what they’re trying to accomplish, and how they’re solving those problems today.
Proto-Persona Mapping: see Lean UX or just wing it with this template. The whole thing takes 30 minutes, and once you home in on the economic buyer (I would use a deeper process like empathy maps or the 5 Rings of Buying Insight), you can shape your product features, positioning, and GTM plan in a single brainstorming session.
IRL Customer Interviews: just wing it; it’s so much easier than you think. Books and courses will teach you to spend days preparing scripts, but I’ve literally just wandered into prospect businesses, chatted up the owner, and walked away with enough insights to fill a dozen Miro boards. Don’t overthink it. If you’re really scared and want training, YC Startup School is here to help.
Bribe Your Research Subjects: reticent or hard-to-reach interviewees? In one case, I gave out $50 Amazon gift cards—even filthy rich executives (my buyer persona) went for this; everybody loves cheap Chinese garbage from the bald man. I got 200 interviews over 2 months for $10K total, not even a fraction of a percent of a seed round.
Diary Studies: if you’re working in a space where you are not the customer, take a few of those customers you befriended during the interview phase and run a Diary Study. This ensures your journey maps are based on reality, not vibes. People are notoriously bad self-reporters, and an interview alone won’t give you the full picture.
Jobs to be Done (JTBD) Everything: this is the highest-leverage framework for orienting in the product jungle, bar none. Learn it from the source rather than a lukewarm reheated overview in a Medium article somewhere. You can extract JTBD from customer interviews and extend your persona maps to get to the heart of what drives product consumption. It forces you to confront and come up with a crystal-clear answer to “what actually matters to my customers? How do I help them <make more money>?” or, as Bezos said, help them “focus on what makes [their] beer taste better.” It’s the surest way to get out of the solution-looking-for-a-problem engineering trap.
Service Design / Journey Mapping: there are a billion types of journey mapping, so do Current State (aka Experience) Mapping in particular—this focuses on understanding how customers presently solve their JTBD. Then, think through how your product will augment or solve this better with a Service Blueprint (service design is especially useful if it involves choreography between customers, technology, and solution providers for the customer to actually solve their problem/make some money with your product). This one is more involved and could take a whole week, but conservation of matter applies, and you have to do this work anyway, whether you front-load it or not.
Define the Product
With personas, journey maps, and JTBD in hand, you can now define a minimum viable product (MVP) that solves the customer’s problem better than the status quo.
Know the Minimum Bar for Your Segment: every product category comes with built-in user expectations for a minimum feature set. If you don’t provide these baseline features, you’re unlikely to close anyone. For example, if you make payroll software, then you wouldn’t ship without support for hourly and salaried employees. Everyone has it; customers expect it. But if you ship only the expected features, there is no reason someone would choose you over an established incumbent. This is where MoSCoW, coupled with a walk-over of your competitors’ feature matrices, can help identify all the “must-haves.”
Minimum Lovable Product (MLP) over MVP: brutalist MVPs aren’t a real market test, and you’ll end up abandoning good ideas simply because early adoption data looks bad. Use the Kano model to identify a few “delighters” that will differentiate you from existing offerings, and focus the majority of your development effort on those. As your business scales and your product reaches more people, you can replace these qualitative methods with MaxDiff studies (perceived relative utility of different features) and TURF Analysis (which cocktail of high-utility features will activate the most customers). Even simple inline one-question surveys can build a dataset sufficient for TURF; we’re not talking about a huge outsourced study or a lengthy email survey customers ignore.
Four Fits Check: verify that the economics of your product make sense with Brian Balfour’s Four Fits Model. Even though it’s mostly a lightweight internal discussion and some pondering, don’t skip this! I have often found very legit JTBD with clear customer propensity, but the actual economics are untenable. For example, SMBs have horribly low WTP, forcing you into a freemium or low, fixed-monthly pricing structure (Model/Market fit). However, B2B software often demands outbound sales and hands-on onboarding, which is massively expensive. Your CAC will eat your LTV alive, failing channel/model fit. That means you either need WTP off the charts (perfect PMF solving an extremely acute pain) OR something that supports self-service onboarding and spreads via SEM/PLG, which severely constrains what you can offer.
Brand, Identity, and Marketing in One Fell Swoop: what you call yourself and how you describe the offering really matters—are you an “accounting suite” or a “payroll processor” or a “wage management solution?” In a previous venture, we used to spend ~half our initial demo call just explaining “we’re not Splunk.” This was literally a totally different thing that couldn’t solve the same problem. Still, the comparison happened naturally because we used similar positioning/language, and it killed several multimillion-dollar deals. April Dunford’s Positioning framework can solve this and compress months of competitive analysis and market development work into a single day. You’ll walk away with a Unique Value Proposition (UVP), a Unique Selling Proposition (USP), and guidelines for how to brand/communicate so you reach an audience that can understand what you’re offering and avoid unflattering comparisons.
Synthesize and Lint Your Product Plan with a PRFAQ: with all of the above in hand, an Amazon-style PRFAQ puts everything into a single, brief artifact written in the language of your actual customers that makes it immediately obvious if this all adds up to a coherent, viable product or not. If that’s not your cup of tea, a Lean Canvas is just as effective. You can complete both in an afternoon.
Start Executing with Riskiest Assumption Tests (RATs): capture the key assumptions you’ve made in all the activities above, analyze them through the lens of Cagan’s 4 Risks (value, usability, feasibility, viability), and do the fastest/cheapest thing that can confirm or reject each assumption. Sometimes that’s building and shipping; sometimes it’s a customer interview; sometimes it’s a paper prototype; other times you can do a low-tech in-market test with manual human labor. I love the example from Fall in Love with the Problem, Not the Solution (page 61) of validating a parcel pickup service using Facebook + WhatsApp + humans. This applies easily to both new products/startups and incremental improvements to existing products. In fact, big established products can have such long cycle times and morale issues that a RAT can save you multiple quarters of dev-team effort, plus the burnout/rage-quitting that come when a launch fails.
Measure and Steer
Once your product, you know, exists, it’s time to continuously iterate and improve. This encompasses both the initial hunt for PMF and then growing your market share once you find it.
Repeat Usage is the Only Real PMF Signal: in the early days of any launch, product metrics like AARRR are “fine,” but the real thing you should be obsessed about is repeat usage. This differs from retention and activation; many people buy crap and never use it. A customer choosing to come back and use your thing again and again is the most unambiguous signal that you are actually solving a real, valuable problem for them. If you aren’t seeing repeat usage, your product either doesn’t work, or it isn’t reaching the right customer—change your product or change the GTM to reach the right persona.
Avoid Premature Market Segmentation: defer introducing differentiated tiers and product packages as long as you can. I know every SaaS under the sun has the same stupid 3-tier pricing page—you should not. One price, one package, that’s it. It’s very easy to get wrong and create awkward adoption-blocking pricing jumps or to implicitly signal “this product isn’t for you” to a persona you hadn’t even thought of but who would otherwise love your product. Instead, identify metrics that signal the customer has received value from the product, and ensure their bill tracks proportionally with that perceived value. As you grow, you might identify clusters of users who gravitate toward certain usage patterns, which can provide a jumping-off point for defining SKUs and alternative billing models. All the other methodologies here basically do not work unless you are enormous (key driver analysis, MaxDiff, Van Westendorp PSM), and even then I would still reach for value metric clustering first.
Satisfaction Surveys are for Early Stage: paradoxically, you should be obsessed with NPS and CSAT early on and care less and less about them over time. When you have a few dozen users, anyone who bothers to respond gives you extremely high-signal feedback in an otherwise data-poor environment. At this scale, you can even follow up with the customer directly. Once you have thousands of customers, other data sources are available and more “honest,” since people often take out their arbitrary frustrations on your survey. A new feature might poll miserably because something else entirely in your product has pissed off the customer, and this is the first exhaust port. Still useful, but it shouldn’t drive all your decisions.
Learn Real Stats: don’t let bogus math mislead your company. As metrics and data become more central to your process, run calibration studies (aka A/A studies) to understand how much your key metrics vary. You can use this information, along with your sample size and statistical power requirements, to calculate your minimum detectable effect (MDE)—the smallest change your experiments can reliably detect. I’m glossing over a lot of statistics, but you can imagine how this helps you avoid overreacting to metrics; e.g., don’t pivot your whole roadmap because month-over-month retention increased by 2% when your MDE is 4%; that could be random noise.
Delete Features: trimming underperforming features is also important over time for sustainability and product comprehensibility. Products all too often accrue features until it’s unclear what they are, who they’re for, and how to use them. If you feel any compunction to invest in “solution guides” or “customer success managers” or “in-product onboarding tutorials” or the like, STOP. Only reach for such band-aids when you cannot simplify your product any further. Someone is gonna cry when you delete features, but instead of being held prisoner, run an Ablation Study (remove a feature in an A/B test and measure the quantifiable hit). Too often, teams take the first sign of user discomfort as a signal to reverse course and bloat their products/codebases.
Explicit and Intentional Strategy Updates: As your business grows more complex, you’re liable to lose sight of both the fundamental strategic decisions you’ve made and how all the work supports and connects back to that strategy. Make this explicit by codifying your product strategy using the Decision Stack. Then, use Opportunity Solution Trees to ensure your initiatives ladder up logically to the business strategy, and update that strategy as your chosen bets succeed or fail. At this point, you probably have a pretty big team with lots of conflicting opinions—use facilitation tools like Current Reality Trees and Evaporating Clouds from Theory of Constraints to collaboratively explore and align on strategy kernels (diagnosis, guiding policy, coherent action).
Just Enough Process
Notice how all of these are effectively thinking tools, not communication tools. No PRDs, 5-pagers, strategy docs, or slide decks. There’s no performance art here. This is all the actual hard thinking that goes into making a good product and a sustainable business. Instead of happening scattershot (or only after something blows up, or not at all), it’s expressed as a series of simple exercises you can finish in hours, solo or in a small group, whenever the time is right for your venture.
In the end, any artifacts you generate need not be polished, but I won’t call them purely throwaway. You need a way to preserve and communicate all this thinking, especially as your company grows and you start delegating work to both humans and AI agents. A few practical tips:
Everything should eventually end up as a Markdown file somewhere (checked into a repo, in a shared filesystem, etc.). You don’t need to live out of a text file! Use Google Docs! Use Miro! Use LucidChart! Use whatever you want! Just export it to something machine-readable when you’re done.
Record and transcribe the meetings where you run these exercises and all of the follow-up discussions. It’s often this talk track that has the most valuable context. Both Miro and FigJam have built-in AI tools for summarizing your sticky boards and collaborative canvases.
Don’t bother compacting any of this down to a single document. Premature distillation is worse than context stuffing with the GPT-5+ model generation. New joiners shouldn’t have to read through the mountain of garbage this process generates; they can point their favorite LLM at your newly amassed context hoard and ask questions.
None of this requires a VP of Product, a dedicated research organization, or a six-month planning cycle. A full run through of the “Understanding Your Customers” and “Define the Product” is maybe one week of effort total. Building may have gotten cheaper, but it’s still an order of magnitude more effort than thinking!