How to Run Continuous Discovery When You’re the Only PM
The continuous discovery playbook assumes you have a UX researcher. Maybe a research ops person. A designer who can help you synthesize. A team that can rotate through customer calls so no one person carries the load. Continuous discovery solo PM life, where you’re the only PM and none of that support exists, is a different exercise entirely.
Most PMs don’t work at a company with that kind of research support, and most reading this probably haven’t either.
Running continuous discovery solo is different. It’s not impossible, it’s arguably the default state for most PMs at companies under 100 people, but it requires stripping the methodology down to what’s actually essential and building habits that survive a week where everything else is on fire.
What Continuous Discovery Actually Means for a Solo PM
Teresa Torres defines continuous discovery simply: weekly touchpoints with customers, focused on the problem space, with the goal of informing decisions. Not monthly. Not “when we have bandwidth.” Weekly.
That sounds brutal when you’re the only PM. It’s not, if you do it right, but you have to be willing to redefine what a “touchpoint” looks like. A 60-minute structured interview every week isn’t sustainable solo. A 20-minute call with a customer during their onboarding, or a 15-minute follow-up after a support ticket, or a 10-minute session shadowing someone using a new feature, all of those count. The goal is continuity of contact, not a specific format.
The mistake most solo PMs make is treating discovery as an event rather than a habit. When it’s an event, it has to be scheduled, prepared for, synthesized, shared, and when you’re overwhelmed, the event gets cancelled. When it’s a habit, it just happens.
Why Solo PMs Stop Doing Discovery (and What That Costs)
The rationalization is always the same: “We’re in a crunch. I’ll get back to users after we ship this.”
After is when the feature lands in front of real users and doesn’t work the way you expected. After is when you find out that the problem you solved wasn’t the one they actually had. After three months of support tickets that trace back to an assumption you never validated.
Take a common version of this mistake: a solo PM at a 25-person logistics tech startup stops talking to users for one full quarter because the team is heads-down on a major integration. The integration ships. Adoption comes in at half what was projected. Three user calls in the week after launch reveal that the setup flow requires a step the users’ IT departments block by default, something that would have surfaced if the team had kept talking to people while building.
The cost of stopping discovery isn’t immediate. It’s paid at launch, in the form of fixes and rework. The metrics dashboard will tell you something’s wrong. It won’t always tell you why, dashboards are good at surfacing that a drop-off happened and bad at explaining what a user was thinking in the moment they gave up.
A useful rule for any solo PM: no quarter goes by without at least one active customer conversation logged every single week, no matter what else is on fire. It’s a low bar on purpose. The point isn’t rigor, it’s that the habit never fully lapses long enough to need rebuilding from scratch.
There’s a second, quieter cost that’s easy to miss at first: when discovery lapses, the gap doesn’t just delay learning, it gets backfilled with whatever’s loudest. Support tickets, a single vocal customer, an executive’s pet theory about what users want. None of those are wrong, exactly, but they’re not representative either, and a solo PM under time pressure will reach for whatever signal is easiest to find rather than whatever signal is most true. The weeks you skip discovery are exactly the weeks your prioritization gets most distorted by whoever happens to be talking loudest at you.
The Minimum Viable Discovery Rhythm
This is the system that holds up under real pressure:
| Cadence | Activity | Time | Output |
|---|---|---|---|
| Weekly | 1 customer call (20–30 min, informal) | 30 min total with scheduling | 3–5 insight notes in running doc |
| Weekly | Review of support tickets + feature requests (batch) | 20 min | Tagged themes |
| Biweekly | Synthesis: what are we learning? | 30 min | 1 updated opportunity area or assumption |
| Monthly | Share with the engineering/design lead | 30 min | Team awareness, surface surprises |
| Per sprint | Tie 1 discovery insight to the sprint’s focus | 15 min | Living connection between learning and building |
Total per week: roughly 75 minutes at the weekly cadence, 90 minutes on biweekly weeks. That’s the floor. Not the ideal, but the version that holds up when everything else is demanding your time.
The key is the running doc. Not a fancy Notion database. A Google Doc or Notion page with a running list of conversations, dates, and three-to-five bullet points per call. That doc becomes the memory.
How to Run Continuous Discovery as a Solo PM, Step by Step
Start with existing access. You don’t need a formal research recruiting process. You need a list of customers who’ve opted into talking to you. Build that list from: customers who’ve submitted support tickets in the last 60 days, customers who’ve been in the product more than 3 days but haven’t completed a key action, and customers who left a positive or negative NPS response with a comment.
Use jobs-to-be-done framing, not feature-request framing. The worst discovery question is “What features would you like to see?” Better: “Tell me about the last time you tried to do X, and it didn’t go well.” The goal is to understand the surrounding context, not to collect requirements.
Separate learning from validating. Discovery isn’t the place to test your solutions. It’s the place to understand the problem. Conflating them means you go into calls with a confirmation bias that shapes what you hear.
Recruit for the next call while you’re on the current one. This is the single habit most likely to keep a discovery cadence alive through the busiest quarters. At the end of every call, ask who else on their team deals with the same problem, and whether they’d introduce you. Solo PMs who let their pipeline of willing customers run dry are the ones who quietly stop doing discovery, because finding someone to talk to becomes its own project.
Bring engineering in occasionally. Even one engineer joining one customer call per quarter builds empathy that documentation can’t create. The product review meeting is the natural venue to share what you’re hearing, but there’s no substitute for hearing it directly.
For context on the formal methodology behind all of this, continuous discovery as a framework is worth understanding, but don’t let the formal version intimidate you into doing nothing. Torres herself has argued that anyone can start continuous discovery today, even inside a feature-factory culture, by story-mapping whatever’s already on the roadmap.
What to Do With What You Learn
Discovery that doesn’t affect decisions is just interesting. The discipline is connecting what you hear to what you build.
The simplest version: for every insight that feels significant, ask “what would we do differently if this is true?” If the answer is “nothing,” it’s good background knowledge but not actionable discovery.
Keep an “assumption log,” a list of the assumptions underlying your current roadmap. Discovery either validates them or challenges them.
After a product launch, the discovery rhythm shifts. You’re no longer in problem space, you’re in validation. Same conversations, different questions: “Did this solve the problem?” and “What did we miss?”
When the System Breaks Down
The rhythm breaks when a crisis hits. That’s fine. One missed week isn’t a problem. Three missed weeks and you’ve lost the habit.
The fix is keeping the bar low enough that it survives the bad weeks. One call. Twenty minutes. Three bullet points of notes. Don’t try to catch up by cramming four calls into one week after a gap, that’s a sprint, not a habit.
The harder thing to manage is what happens when discovery is surfacing problems your roadmap isn’t addressing. The answer isn’t to stop listening. It’s to be explicit that hearing something doesn’t mean building something immediately.
One more thing worth naming for anyone doing continuous discovery solo PM work specifically: at some point, you’ll be the only person in the company who’s actually heard the customer pain firsthand. You’re not going to win that argument by asserting authority, you win it by having the running doc, with dates and specifics, ready to pull up in the same meeting.
Start this week: make a list of five customers you haven’t talked to in the last 30 days. Pick one. Send a two-line email asking for 20 minutes. That’s the whole system.
References
