In product development, it’s easy to move straight from idea to implementation. A stakeholder suggests a feature, it sounds reasonable, and the next thing you know it’s in a backlog somewhere. But discovery - the space between idea and ticket - is where so many product decisions either gain clarity or go completely off the rails.
The truth is, discovery often isn’t formalised. And when it is, it’s too heavy, too rigid, or only happens when there’s enough time. That’s where a lean, structured, but flexible workflow can make a world of difference.
More often than we’d like to admit, teams are working on the wrong problem.
Stakeholders will confidently say the problem is X - but after digging deeper, it turns out to be Y. In the rush from feature to feature, you rarely stop to challenge those assumptions. And that’s not because you’re doing something wrong - it’s because product life is messy, and the textbook version of discovery doesn’t always fit reality.
This is why formalising a lightweight process matters. Just like A/B testing exists because we don’t always know what’s going to work, discovery workflows exist to give space for uncertainty, exploration, and iteration - before you commit valuable resources.
A lean system like Produmo embraces this. It doesn’t try to make the mess go away - it gives it structure.
When we say “lightweight,” we don’t mean shallow. We mean adaptable.
A good discovery workflow doesn’t prescribe ten steps and a gate review. It’s a flexible loop: investigate, collaborate, validate, decide. Some ideas will take 30 minutes. Some will take 3 weeks. The point is having just enough structure to catch issues early and keep forward motion.
Right now, most tools are insular. You’ve got ideas coming in from all angles - user feedback, exec offsites, competitor research - and they all live in different formats, across different tools. You might get a Slack message with a feature request, a Notion doc with design specs, a Figma prototype someone shared in a meeting, a Miro board from a brainstorming session, or a Google Sheet of user feedback. Every tool serves a purpose - but none of them talk to each other. Product managers end up managing the chaos manually, juggling formats, links, and updates across platforms.
Here’s how we think about it - but remember, you don’t need to have all the answers up front. Sometimes you’re still figuring out who the user is or what the real problem looks like. That’s the point of discovery.
This cycle doesn’t need to be fancy—but visualising it helps. (See diagram below.)
Feature discovery doesn’t start with a roadmap. It starts with a spark—some trigger that makes you pause and think, "Is there something here?"
Sometimes, those sparks land in your lap. A stakeholder asks for a feature in Slack. A user logs a support ticket about a painful workaround. You overhear the sales team struggling to explain something on a call. These are your reactive sparks - feedback, complaints, or ideas that surface because someone is already feeling the pain.
But not every spark is reactive. Some of the most meaningful opportunities come from being proactive. Maybe you're digging into your funnel data and notice a sudden drop-off. Or you're watching user tests and catch a moment of hesitation - something no one reported, but it clearly signals friction. Sometimes it’s subtler: a pattern in written feedback from NPS surveys, a heatmap click that makes no sense, or just an itch you can’t quite explain yet.
At one company I worked with, we blocked out an hour for daily standups - but the actual standup took 10 minutes. Product would use the extra time to bring up messy, unresolved business problems. One day we said, “The post-sales team are constantly struggling to track changes to bookings. Why?” Everyone was there - design, engineering, even the CTO. We started throwing out theories, asking questions, sketching systems on a whiteboard. We didn’t solve it that day, but the spark had been lit. That one conversation seeded three future features.
And that’s the thing - sparks aren’t always feature ideas. Sometimes they’re just a hunch. A sense that something's not working quite right. You don’t need a spec or a solution. You just need to catch the moment and write it down before it disappears.
So whether it’s a customer quote, a funnel metric, or a conversation you can’t shake - capture it. Stick it on a post-it. Drop it in your discovery tool. Tag it for later. Give it just enough structure that future-you will know why it mattered.
The earlier you start tracking these moments, the easier it becomes to spot the real opportunities when they show up again.
Once a spark has your attention, the next step is figuring out what it actually means. And this is where things can easily go off course - because most stakeholders won’t come to you with a clearly defined problem. They’ll often bring what they think the solution should be. That’s not a flaw; it’s just how people think. As product managers, it’s our job to take a step back and ask: is this truly the right path forward?
In fact, I used to actively encourage the mindset: “Don’t come to me with a solution. Come to me with a problem.” But in practice, that rarely happens. So you have to assume that every suggested solution might be pointing at something deeper - and dig until you uncover what that really is.
This is where you slow things down and start asking the unglamorous questions:
Sometimes the issue is obvious, but more often than not, the clarity comes through conversation, observation, or simply letting the idea breathe a bit longer. You’re not trying to write a case study - you’re just trying to understand what’s broken, and why it matters.
A rough hypothesis is enough. Something that frames the tension, the impact, and the user group. That small amount of structure gives you a much better chance of deciding if the idea is worth exploring further - or if it’s not the right moment yet.
And here’s why it matters: finding out you misunderstood the problem after you’ve started development - or worse, after release - is far more expensive in time, money, and trust. I’ve been there. It happens. But when it happens on a big feature, or under tight timelines, it can derail everything. That’s why this phase is worth slowing down for.
Now that you’ve got a rough idea of the problem, the natural next step is to ask: Is this worth solving right now?
This is where you dig deeper - not to find the final answer, but to get a sense of whether the idea has legs. That might mean looking at data, chatting to users, checking what the support team has heard, or asking other PMs if this has come up before. The goal is to validate the potential, not just the problem.
You’re not proving the solution will work - you’re trying to learn enough to justify spending more time on it. Is this a real need? Is it painful? Is it frequent? Who benefits? Who might be impacted?
Sometimes, the idea fizzles out - and that’s fine. You learn something, tag it, and move on. Other times, it opens a whole new area of opportunity. I’ve had “small” ideas turn into strategic projects just because we realised, through early exploration, how interconnected they were with other problems.
This phase is also where things tend to stall if there’s no structure. Maybe you’re waiting on data from analytics, or a user research session, or a colleague who’s deep in another project. Without clarity on what “done” looks like in discovery, the idea can sit in limbo. That’s why it helps to write down what you’re trying to validate - so you know when you’ve got enough to move on.
You’re not committing to build. You’re committing to learn enough to make a smarter decision. And honestly, that can be a tough sell to the business. Early discovery doesn’t always look productive on the surface. You might be talking to users, analysing data, scribbling ideas in FigJam - but not shipping anything yet.
Some stakeholders will get it - especially if you frame it as "measure twice, cut once." But many won’t. Particularly if the idea seems obviously good, or worse, comes from someone senior. That’s where the temptation kicks in to skip discovery altogether.
A few years into one role, I spotted something early on: we were investing loads of energy into acquiring new customers, but post-sales was quietly falling apart. The volume of support requests was growing, but nothing on the dev roadmap was aimed at helping the post-sales team. It didn’t take much to realise we were heading toward burnout, unhappy customers, and a possible reputation hit.
But I didn’t act on it properly. I didn’t build the case. I didn’t quantify the pain or scope the work required. I hadn’t explored the potential. So when I raised it, I couldn’t answer the most important question: Why should we spend money here? And without that, nothing moved.
Lesson learned. If something feels important - prove it. Don’t just assume others will see it too.
Working solo on a problem doesn’t mean you’ll definitely miss something - but it raises the odds. You increase the chances of missing context, missing edge cases, or simply not creating the best solution possible. More heads really are better than one - especially when those heads bring design, technical, and business perspectives to the table.
Earlier in my career, I had a habit: a stakeholder would bring me a problem, and I’d go away and solve it. On my own. I’d map out the whole thing, create detailed wireframes, and then write what I thought were beautifully crafted stories in Jira. I took pride in the quality and clarity of those tickets.
And then I’d take them to the dev team - and they’d find holes all over the place. Sometimes I’d misunderstood the problem entirely. Sometimes my solution only half-solved it. Other times, I’d designed something that just couldn’t be built the way I imagined.
The first few times this happened, I was disappointed. After that, I got frustrated. I’d rant to my husband in the evenings about how unfair it was, he - who’s a developer - pointed out something I needed to hear: I wasn’t using the team to solve the problem. I was trying to do it all myself, and just expecting them to build it.
So I changed tack. I tried bringing raw problems into planning sessions and asking the team to help shape the solution from scratch. But that didn’t quite work either. When there’s nothing to respond to, the conversation can stall. It’s hard to have ideas in a vacuum.
Eventually, I found the middle ground. I’d write up a rough hypothesis or high-level solution - just enough to spark conversation, but not so much that I was emotionally attached. We’d go into a session, use that as the starting point, and collaboratively shape it into something better. Often my original idea wasn’t completely discarded - it became the foundation we built on.
At around 80% confidence, I’d go away and polish the stories, flesh things out with design, and work through any final gaps. If I hit a major blocker, we’d bring it back into the group.
This rhythm became the backbone of how our team worked. We had a phenomenal group - logical, open, collaborative - and it worked because we trusted each other and left egos at the door.
But not every team is like that. Some need more guidance. Some aren’t used to being included early. So you adapt the level of collaboration to the people in the room. But no matter what, some form of early collaboration will almost always make the idea stronger - and make delivery smoother.
Eventually, every idea reaches a point where you have to decide what to do with it. That doesn’t mean it’s ready for engineering. It just means you’ve explored it enough to make a call.
And a decision doesn’t always mean building. Sometimes it means pausing it, shelving it, or saying "not now." But without this step, discovery work often drifts - half-finished thinking that never fully dies, and never fully moves forward.
A decision isn’t just “yes” or “no.” It might be:
So, how do you decide if you should move forward with a feature or not?
For me, a few things tend to tilt the scale:
But just as important as saying yes is being intentional when you say no. This is something I had to learn the hard way.
No one ever taught me to write down why we weren’t moving forward with something. So year after year, the same feature requests would resurface. I’d vaguely remember looking into it before - but I could never remember why we dropped it. And with everything else going on in my head, it would slip through the cracks.
So here’s the habit I now swear by: if you decide not to move forward with an idea, record it. Write down what was missing. What you were waiting for. Why it wasn’t a good fit then. You’ll thank yourself later.
Not every idea belongs in your backlog. But every idea deserves a decision - and a clear explanation of why it was paused, progressed, or passed on. That small piece of context can save your future self (and your team) from confusion and repeated conversations.
Even with good intentions, feature discovery can still get derailed. Here's how to spot the signs—and what to do about them:
Too many voices, not enough alignment: You’ve got a room full of stakeholders, and instead of alignment, you get chaos. Everyone has an opinion, but no one agrees on what to do. If you’re having the same discussion multiple times with no movement, this might be your red flag. To move forward, reduce the size of the group, clarify ownership, and bring data or user insights into the conversation to anchor the debate. A big red flag is walking away from one of these sessions without clarity. If you’re unsure what the next steps are, you’ve likely hit this misalignment head-on.
Turning discovery into delivery too early: The idea is promising, and someone’s keen to “just get it into Jira.” But the moment you write a ticket or assign a deadline, it’s emotionally committed—even if it’s half-baked. If the team is designing, estimating, or grooming without validation, take a step back. Check: do we actually understand the problem yet? Has anyone validated this? Discovery is for learning, not shipping.
I’ve worked with people who wanted us to move quickly—and sometimes, that’s necessary. Businesses are there to make money, not always to craft the most elegant or ‘perfect’ solution. But the idea that Agile simply means fast is a misunderstanding of what Agile is truly about.
The phrase isn’t “Develop early, develop often, and develop forward.” It’s “Fail early, fail often, but always fail forward.” And failing in the discovery phase is failing early—just with far less cost and far more opportunity to pivot. Let discovery do its job. It’s the cheapest way to be wrong.
No validation step: “It’s a small feature, we don’t need research.” Famous last words. Even small changes can lead to friction or missed expectations. If you find yourself justifying skipping validation because it seems simple, pause. A quick user check, a review of support tickets, or even an internal gut-check session might save a lot of rework later.
Even as I write this though, I know this is best case scenario. I’ve taken the shortcut before—“just add the dropdown, what harm can it do?” And sometimes, it's fine. Sometimes it really is easier than having a three-hour philosophical debate about a field label. But just know, when you do skip it—and you will—the cost may still come. It just might show up later, and you need to be ready for that.
No decision point: You’ve been talking about the same idea for weeks. It’s been in ‘discovery’ forever. But no one knows whether to move forward, pause, or kill it. If you’re in this loop, write a short summary of what’s been explored, what’s missing, and propose a call. “We’ve done X, Y, and Z. Do we move forward or not?” It helps anchor the conversation and drive clarity.
A lean discovery system won’t stop these challenges entirely—but it will make them easier to spot, talk about, and resolve.
A lean system helps prevent these traps by gently guiding the process without over-controlling it.
The point of lean discovery isn’t to do less thinking—it’s to do just enough of the right kind.
The way I’m building Produmo, “lightweight” doesn’t mean shallow. You can go deep when needed. Add validation tasks, get cross-functional input, and dig into data. But it’s still lighter than the cost of starting development, involving five roles, and then realising halfway through that you’re building the wrong thing.
When that happens, you’re either facing a sunken cost fallacy or a very difficult decision to pull the plug. Neither is fun.
Most ideas shouldn’t be built. That’s just the reality of good product management. But here’s what happens: we pause them, forget why, and later revisit them without context.
"Didn’t we already look into this?"
"Wasn’t there a reason we said no?"
"Oh yeah… we needed to talk to data, but then we got busy."
This is why it’s so important to keep a visible record of what’s been explored, what was paused, and why. Not for bureaucracy’s sake - but so your future self and your team don’t waste cycles re-investigating something you already ruled out. Sometimes, the context will have changed - new goals, new leadership, new constraints. But you want to be revisiting these ideas with clarity, not guesswork.
A lightweight discovery system should support this. Even a simple tag like "paused" with a short note - waiting on Q4 data," or "low usage - no stakeholder interest" - can save hours down the line.
You don’t need a heavyweight process to get discovery right. You need:
A lean discovery workflow helps you build the right things - not just ship things.
And that’s where the real product magic happens.