Early work on any big thing should give you value, risk mitigation, and learning. You’re not just laying the groundwork to get those sometime in the future.
Most big initiatives start with a first slice that’s too big, too obvious, or too fuzzy. Teams spend weeks or months on early work that doesn’t create value, reduce risk, or teach them anything meaningful. Feature Mining offers a practical way to slice through that core complexity. It helps a team see the real sources of uncertainty, align early around what matters, and design a first slice that is small, meaningful, and grounded in real outcomes.
In this episode, Peter Green and Richard Lawrence explain how Feature Mining works and where it came from. They share a real example from retail, walk through the core steps, and show why the method creates early traction, shared understanding, and a smarter path through complex work. You’ll see how teams use Feature Mining to avoid months of waste, kill weak ideas early, and build momentum with fast learning and visible value.
If you’re dealing with cross-team dependencies on a big initiative, you may also find Episode 205 helpful:
Three Strategies to Reduce the Pain of Cross-Team Dependencies
Links Mentioned in This Episode
- Episode 205: Reduce the Pain of Cross-Team Dependencies
- Download the Story Splitting Patterns
- Newsletter: How You Start is Everything
Go Deeper
- Take the 80/20 Product Backlog Refinement Course. Use coupon code BLACKFRI2025 for $50 off through 11/30/2025.
- Register for a CSPO Workshop. Use coupon code BLACKFRI2025 for $100 off through 11/30/2025.
- Register for the A-CSPO Program. Use coupon code BLACKFRI2025 for $100 off through 11/30/2025.
- Become a Certified CAPED Consultant. Use coupon code BLACKFRI2025 for $100 off through 11/30/2025.
- Contact Us if you’d like help facilitating Feature Mining for your next big initiative to get early value, learning, and risk reduction.
* Not valid with other offers or discounts.
Episode Transcript
Richard Lawrence: Welcome to the Humanizing Work Show. I’m Richard Lawrence here with Peter Green. If you start an initiative the way most organizations do, you’re at huge risk of wasting time and energy and losing credibility. We’ve developed a systematic way to prevent that from happening, and on today’s episode, we’ll walk you through our approach so you can get to value, learning, and risk reduction early in any project instead of waiting until it’s too late.
Peter Green: I’ve been so happy that we have this approach, Richard, because over the last year, I would say probably a half dozen clients have brought us in where they’ve got that big initiative all planned out, or they’re in the very early stages of sketching it out, and want some advice.
These projects have a lot of similarities. We’ve noticed there are lots of different systems they’re trying to integrate and get data out of, different things to conform and be deduped and be clean. There are dozens of features that they consider required to even get to what they’re calling an MVP. They’re using multiple vendors, different departments, multiple teams to work on different parts of the system.
And lots of untested assumptions about which parts of the initiative really matter. What are customers going to use? Where’s the value? What will never get used? What should we avoid building? Thankfully, we’ve been able to jump in and help them avoid the two usual paths: comprehensive analysis, where everything is mapped and architected up front, or the quick-win approach, where they fire up a new data warehouse or similar and call it progress.
Big initiatives often start with one of those steps. It’s the wrong first slice. It’s either too big, too obvious, or too haphazard. And in a recent newsletter called “How You Start Is Everything,” you wrote that early work on an initiative should do five things. Would you summarize those?
Richard: Early work on any big thing should give you value, some risk mitigation, and some learning. You should know more than you did when you started, instead of just confirming what you already believed. It should create motivation because people are making meaningful progress. And it should give you credibility because stakeholders can see you’re doing something useful.
The paths these clients were taking weren’t likely to give them any of the first three for months. Not much value. Not much risk reduction about whether this thing will be useful. Not much learning, especially customer learning.
Peter: Yes, and when clients take those other approaches, the first slice often takes way too long. Sometimes things have changed by the time they deliver anything.
That big slice often requires huge dependency maps and coordination between teams. (If you want help with that, check out our last episode: https://www.humanizingwork.com/reduce-the-pain-of-cross-team-dependencies/.)
We also see stakeholders think they’re aligned going in, only to discover way too late that they actually had different ideas of what was important.
And teams often get stuck between detailed analysis people and just-start-building people. There’s a third and better way to start, and that’s where Feature Mining comes in.
Richard: I invented this years ago when a couple clients wanted the benefits of good story splitting but earlier, at the level of the first release. We experimented with different ways of getting value, learning, and risk mitigation early, and eventually developed what became Feature Mining.
I slightly regret the name now because it’s not always about features. It’s really about designing probes for complex initiatives. But by the time we realized that, everyone was calling it Feature Mining, so the name stuck.
Let’s walk through a simple example. Imagine a big retailer that does monthly sales reporting. Store managers find out in mid-January how things went in early December. Not very useful. They wanted weekly reporting instead.
The traditional path would be to plan all the changes to the data warehouse, all the reports, all the integrations, and deliver one big MVP months later, which still wouldn’t teach them much. Feature Mining takes a different path.
First, get the right people in the room: problem-space experts and solution-space experts.
Second, name the initiative clearly: in this case, “Weekly Sales Reporting.”
Then brainstorm four lists: Impact, Bigness, Risks, and Uncertainties.
Impact examples: store managers can respond faster to changes in sales.
Bigness examples: lots of data, different regions with different sales calculations, training needs.
Risks: we build it and store managers don’t use it.
Uncertainties: how should the weekly report differ from the monthly report?
Then identify the most important items on each list. Once you have the winners, combine them to ask structured “What if we just…?” questions. For example: “How can we get some of that top impact without taking on all that top bigness?” Maybe do it for one region or one store first. Or simulate the report manually for a few weeks.
That gives you a much smaller slice that still creates value, mitigates risk, and produces learning.
Peter: As you describe this, it reminds me that the biggest risks are usually business risks: will this actually matter to customers? Not just technical risks. If you build a perfect real-time data pipeline but the format isn’t useful, none of it matters.
Richard: Exactly. And in this retail example, the customer complexity came first. The technical complexity showed up next.
Peter: What benefits have you seen over the years?
Richard: First, alignment. The earliest teams using this included way more stakeholders than I expected, but the upside was that everyone felt heard. They understood why we were starting where we were, even if it wasn’t what they originally hoped.
Second, clarity around ROI. Sometimes the loudest or most senior person pushes an idea that isn’t actually good. Feature Mining helps teams see that objectively. I’ve seen bad ideas get killed 20 minutes into a Feature Mining session—with everyone still feeling good about it.
Finally, it builds an agile mindset. People start valuing small slices and early learning, which supports a lot of other good practices.
Peter: Because this has been such a useful approach, we teach it in multiple formats. It’s in the 80/20 Product Backlog Refinement course, our CSPO and A-CSPO classes, and it’s core to the CAPED process.
You can also hire us to facilitate Feature Mining for your next strategic initiative.
Richard: And if you got value from this episode, please subscribe, click the bell, like the video, and leave a comment. If you’re listening on the podcast, we’d appreciate a five-star review.
Peter: Thanks for tuning in to The Humanizing Work Show. We’ll see you next time.
Last updated