Watch for more info on our full suite of CAPED courses and certifications in the coming weeks. These courses are the best of what we’ve been practicing, testing, and refining over the past two decades, and we’re eager to share them with you.

About a month ago, I asked our readers if your team is sufficiently cross-functional to deliver a complete increment of value.

A little under a quarter of responses indicated, “yes, my team is sufficiently cross-functional to complete vertical slices.”

The other three-quarters indicated their team is not fully cross-functional but were split in half about whether that was fine or something that should change.

We’ve worked with a lot of teams in a lot of different contexts, so I expected to hear that many teams were less than fully cross-functional. I didn’t expect the percentage of fully cross-functional teams to be so low.

In future weeks, we’ll share our recommendations for how to nudge team structure in the right direction, especially if you don’t have the power to just decide to make that happen. This week, I want to share some initial reflections on the results of this poll, based on our experience with team structure in lots of different contexts…

If…

• working in small, vertical slices of value is the keystone habit that makes all of the rest of the agile stuff work, and
• only a quarter of people who responded to that poll said their team was set up to use that practice, and
• our mailing list probably selects for people trying to practice agile software development well

…then it’s no wonder people are a bit jaded about agile these days.

To get the results people say they want from agile, it is essential to shape the work to deliver incremental value and to design team structures that support focus and collaboration on that work.

For those of you who have that team structure already, don’t waste it! You have a surprisingly rare opportunity to work in small slices of value, building learning and impact into your work every day.

For those of you who don’t have a functional team but would like to, I’ll share more advice in the coming weeks, but here’s my #1 tip to start nudging things in the right direction: Make it visible. If you can’t fix it, make it visible. In this case, making it visible means identifying the actual value you’re contributing and tracking how it moves between teams and how long it takes to go from start to finish. Work that spans teams often has a cycle time 10x longer than the same work done within a single cross-functional team. Showing real data about that often convinces leaders to adjust team structure.

Thinking about the “not cross-functional, but it’s fine” responses… I don’t have context for those votes, but in my experience, there are three situations where that’s actually true.

1. When value comes from two or more very distinct kinds of work being integrated. The classic example is hardware and software. Some products only deliver marketable customer value when both hardware and software components work together. But putting, say, mechanical engineers and software developers on the same team is usually clunky. The work is so different and runs at such different paces that you end up with two virtual backlogs and two virtual teams pretending to be one team. Better to separate out the work, coordinate closely, and integrate frequently.
2. When your definition of “cross-functional” is bigger than it needs to be. Some skills are needed sporadically or at very predictable times. In those cases, if the skills are available from outside the team when you need them, then you can have a sufficiently cross-functional team without those skills on the team. A classic example is IT skills like server management on a software team.
3. When part of the stack is outside your org. I’ve worked with teams who deliver a service that gets used by multiple outside teams to ultimately deliver value to end customers. It’s still good to think about your work from the perspective of the end customer, but you’re not likely to build a team around that whole stack.

There’s a fourth case that can go either way: The platform or shared component team. If the platform or shared component is mostly non-functional and independent of functionality in the products that use it, this can sometimes make sense as its own work stream. For example, a logging and monitoring component used by various applications in an org.

But much of the time, a shared platform or component is more closely related to the functionality that uses it. And in those cases, it’s often better to have shared ownership among the teams that use it and to layer on a structure for coordinating across teams to keep the shared component aligned.

Did I miss a case? Reach out to tell me about it.

Finally, to those readers who voted “not cross-functional, but it’s fine” mostly because you’ve given up hope of change, I want to encourage you that the right team structure really does make work more effective and more engaging. It’s worth nudging in the right direction. Leaders, team members, and customers all benefit when orgs get this right, but sometimes it can be hard to see how to make it happen. Start by just making the current state more visible, and see if that creates any interest in change.

The post Surprisingly few teams are actually cross-functional…is yours? appeared first on Humanizing Work.

Psychologists call that dynamic precision bias.

The Illusion of Accuracy

Precision bias is our human tendency to use precision and detail as signals for accuracy. If a number looks precise or a document looks detailed and polished, we’re more likely to trust it…whether or not there’s any objective reason to.

This is how all cognitive biases work, by the way. They’re shortcuts that save energy but sometimes lie to us. Unfortunately, while they’re good at keeping us alive, they really undermine product development.

Just in the past week, I’ve seen several PRDs, feature descriptions, and user stories that clearly show LLMs’ fingerprints. And I’ve watched developers treat all the details in those artifacts as true, breaking them down into smaller stories and even BDD scenarios without really asking anything like, “What evidence do we have for this?”

Placeholders, Not Prescriptions

Long before requirements documents were AI-generated, user stories were a response to precision bias in product development. The early eXtreme Programming practitioners noticed that detailed requirements tended to inhibit collaboration. People would ask few questions before diving into development.

So, they talked about user stories as “placeholders for conversations.” A record of what has already been discussed and just enough detail to focus the next conversation. As different decisions need to be made in the life of a user story, there’s a whole series of conversations that lead to more and more detail being captured.

This approach of incrementally and collaboratively adding detail applies beyond user stories.

For example, a very lightweight PRD would be enough as input to a Feature Mining session for an initiative. That cross-functional conversation would produce the first one or two Minimum Marketable Features, which could then be broken into user stories (again, collaboratively). And as the team works on those MMFs, a shared understanding of the initiative emerges, which informs more detail in the PRD, more features, and more user stories.

It’s not just about limiting up-front detail. If you want to create product artifacts that invite conversation rather than shutting it down, there’s also a key language change to consider. Adopt the language of experimentation rather than specification.

Certainty Is the Wrong Goal

Most new things worth building are going to have some complexity to them. So, instead of specifying all the details as if you know the future, be transparent about hypotheses and assumptions. Here’s what we believe to be true. Here’s how we’d know if we were right or wrong.

A one-pager that lays out, at a high level, assumptions about the problem to be solved, the business case for solving it, the constraints on the solution, and the tests that would validate the hypothesis is a great alternative to a detailed specification for an initiative.

It’s natural for people to want certainty. PMs want to communicate clearly and confidently. Devs want to know that they’re going to build the right thing and not have a bunch of rework.

But if you’re solving complex, meaningful problems, early certainty is an illusion. The detail doesn’t make things more accurate. It just lets you potentially build the wrong thing more confidently.

If conversations around your product artifacts mostly sounds like, “Any questions?” (and you’re hoping the answer will be “nope, that all makes sense”), then the documents may be doing too much work.

The best way to use artifacts to invite conversations is to think about the various decisions you’ll need to make together and treat the artifacts as one input to those decisions. For example,

• Where should we start on this initiative?
• How big is this feature?
• How should we break this feature into stories?
• How big is this story?
• Etc.

By writing with the decision in mind, you can avoid capturing unnecessary detail too soon. It’s not, “What’s everything I know or might get asked about for this initiative?” It’s, “What info will set up this conversation for success?”

Here’s a small change you can try this week: Take something complex and match the level of detail to the level of evidence you have. Get explicit about assumptions and hypotheses. And then let detail emerge as you interact with your team around the item.

Go Deeper

Want to learn more about building this way of working into your whole product development approach? Check out our Complexity-Aware Planning, Estimation, and Delivery (CAPED) approach, and join us in an upcoming CAPED workshop or schedule a free consultation to see if the CAPED approach is what your high-stakes initiative needs to succeed.

The post Precision Bias and AI in Product Management appeared first on Humanizing Work.

As I’ve said many time before, vertical slicing—organizing work around small increments of customer value—is the keystone habit that makes all the rest of the agile stuff work.

And I think a lot of people see that. It’s why our story splitting guide is still the most popular thing on our website.

But in most of these vertical slicing conversations, there was an elephant in the room.
Participants enthusiastically worked on their slicing skills. They understood why it mattered. And they got good at practicing it.

Then, at some point, a participant would say, “But our teams aren’t structured to work on vertical slices.” Cue the sad trombone. Because, while organizing work across multiple teams using vertical slices is possible, it’s painful, and it’s much less effective than having teams who can deliver increments of value.

Before I write more about this challenge, I’m curious if these groups were outliers or if this team structure struggle is more widespread. Which of these sounds like your situation? Click the option that best describes your team—whichever you click will take you to a page with a few free resources that might help.

• My team IS sufficiently cross-functional to complete vertical slices​
• My team IS NOT sufficiently cross-functional to complete vertical slices, BUT IT’S FINE
• My team IS NOT sufficiently cross-functional to complete vertical slices, AND I WISH IT WAS​​

The post Vertical Slicing’s Elephant in the Room appeared first on Humanizing Work.

Three Strategies to Reduce the Pain of Cross-Team Dependencies

Even if you can’t change the org chart, you can reduce the friction. Three practical strategies for making vertical slices work when your team depends on others.

Org Structure, Software Architecture, and Cross-functional Teams

Why team structure and software architecture reinforce each other—and what to do about it in the short and long term.

MMFs: What They Are and Why They Matter

The concept behind slicing initiatives into meaningful increments of value. What makes an MMF different from an epic, and why it matters for sequencing.

The Humanizing Work Guide to Splitting User Stories

Our most popular resource. Nine patterns for splitting stories small enough to finish quickly while still delivering value.

Habits and Strategies

Why vertical slicing is one of three keystone habits that make everything else in agile work better.

The post Vertical Slicing and Team Structure Poll – Thank You appeared first on Humanizing Work.

In last week’s CAPED webinar, after we gave an overview of the benefits of tackling complexity early with Active Planning, we asked participants for examples of initiatives that would benefit from the CAPED approach. One participant said, “I can’t think of a large project that wouldn’t benefit.”

Most big things worth doing have a big dose of complexity. They’re new things for humans, usually bigger than what one team can do independently.

But if you haven’t started with the complex part, and you realize it while the project is in-flight, what do you do next?

Feature Mining is our favorite tool for identifying the first slice of a big initiative. But it can also be used to find the next slice in a big initiative.

If you are already working on a big initiative, you can do Assumption and Complexity Mapping from CAPED Phase 1 and Feature Mining from CAPED Phase 2 in parallel with the work that is in-flight. Then take the MMF(s) from Feature Mining, refine them into stories, and move them to the top of the appropriate backlog(s) for their next Sprint.

Sound interesting for what you’re working on?

Learn more about CAPED here.

Or join us at our upcoming Certified CAPED Consultant workshop to get equipped to bring CAPED to your organization.

The post Addressing Complexity Mid-Project appeared first on Humanizing Work.

Then, as the release neared its end, things would get tight, and eventually we’d schedule a meeting to discuss pushing the date out. We’d make tough calls to accept some known quality issues. We’d plan for lots of overtime. And we’d vow that *next time* we’d do a better job.

We recently wrote about that early optimism and late-crisis pattern, especially the need to map core complexity and probe it early. Here, I’ll focus on how we need to change our approach to estimation in order to get better forecasts and make room for probing the core complexity.

When I was in the middle of that experience, it felt like there were only two options. One was to keep repeating the cycle. Build the detailed plan, estimate all the pieces, add them back up, apply some buffering, and hope this time we’d get it right.

The other option was the one recommended by some in the agile community: stop trying to estimate so far out and just do rolling planning every few weeks. I’ve seen that work in two or three contexts. But most executive teams still have to make quarterly financial calls, review strategy and plans with the board or investors, commit budget, and decide where to invest time and people across a portfolio of options. “Figuring it out as we go” doesn’t address the bigger questions they need to answer.

There is a third option, and it has become a core part of CAPED (Complexity-Aware Planning, Estimation, & Delivery). It solves several problems at once. It is much faster than building a detailed component-based estimate. It produces more accurate forecasts. And it gives teams the air cover they need to do Active Planning instead of trying to map every piece of the puzzle up front and hoping the math holds.

The third option is called Reference Class Forecasting. Kahneman and Tversky helped explain why the usual approach goes wrong. When we estimate by breaking the current project into tasks and imagining how they’ll go, we’re using what’s often called the inside view.

Inside view estimation goes wrong in predictable ways. It’s subject to optimism bias: teams genuinely believe they can avoid the problems that hit the last project. It amplifies the planning fallacy: the more time we spend building a plan, the more believable it becomes, regardless of whether the data is accurate or not. It ignores complexity, where some of the most important parts can’t be clearly seen at the start.

So Kahneman and Tversky recommended a different approach: take an outside view. Look at similar efforts from the past. Group them by meaningful similarities. That gives you a reference class. Then look at what actually happened in that class. How long did those efforts take? What range of outcomes resulted? How often did they run long, and by how much?

This turns out to be both faster and more accurate than building a detailed inside-view estimate. You are no longer pretending you can reason your way to certainty from an early task breakdown. You are starting from real outcomes instead.

Reference Class Forecasting works so well that mega-project expert Bent Flyvbjerg uses it on the major projects he advises and writes about it in How Big Things Get Done. It’s well worth reading. A lot of what he describes will feel familiar to our audience, especially the need for active planning and small-slice delivery once a project is underway.

Join our free webinar next week to see how this works in practice. We’ll show how Reference Class Forecasting improves forecasts and how that frees teams to use iterative probe cycles in Active Planning and good Agile practices during delivery, avoiding the early-optimism, late-crisis patterns too many of us have been stuck in for too long.

Register Now

The post Project Estimates Are Better without a Detailed Plan appeared first on Humanizing Work.

I’ve talked with Product Owners who are up at 5am for daily stand-ups with offshore devs and still have a full calendar of US meetings until 5pm.

This is exhausting for the people involved. And it also makes it very hard to address complex problems.

Complex problems—like creating new software capabilities for humans—have emergence. Doing the work teaches us what the work is. New data about the problem and the solution emerges as we begin creating the solution.

Making sense of that emerging data usually requires collaboration between multiple people. And if those people are spread across time zones, that collaboration is necessarily going to be delayed. What would have been a 15 minute conversation if everyone were working in the same office or even interacting live over Zoom or Slack becomes 2 days of back-and-forth.

Even then, there are often more multi-day loops as it becomes clear everyone wasn’t as aligned as it seemed.

At best, this means delays for a project. More often, it’s delays plus burnout as people work long days to try to work around the time zone gaps and shorten the feedback loops. As delays add up and everyone is running on fumes, you have less time to deal with emerging issues and even less mental capacity to handle them well. Delivering a successful result requires heroics or doesn’t happen at all.

Our CAPED (Complexity-Aware Planning, Estimation, & Delivery) approach can mitigate the pain of doing complex work with distributed teams.

It doesn’t make the complexity go away. But by identifying and probing the core complexity right from the beginning, CAPED front-loads those feedback loops and the intense collaboration for the time when energy and engagement is highest at the start of an initiative.

Then, as the complexity gets resolved, work moves into the complicated domain, and it’s much easier to coordinate across time zones. Projects move into a sustainable steady state without all those long email threads and early or late Teams meetings.

Are you tackling a high-stakes initiative with a distributed team? Join us for a free webinar later this month to learn how CAPED can help you.

Register Now

The post Using CAPED to Survive Big Time Zone Differences appeared first on Humanizing Work.

One participant picked a request from a particularly upset stakeholder. He had submitted a ticket asking for an urgent change, and the language was unusually terse and demanding. When they met, she started to use the situational question from class, which lowered the temperature enough for her to see what was really at stake. There was an audit finding involved. Leadership was asking questions. He wanted to move quickly.

And as they explored the situation, it became clear to both of them that the problem was not actually in the tool. It was a process interpretation issue that had built up over time through manual workarounds. The audit finding turned up the pressure, and under that kind of pressure people often point at the most visible thing. In this case, a system fix would have taken time and still left the actual risk in place. What they needed was training so people could follow the process well enough to stop creating the workarounds.

That shift happened because she did not start by arguing with his solution or rushing to accommodate it. She started by asking what had been happening. If she had taken the request at face value, her team could easily have burned a sprint solving the wrong problem.

There was more to this, though. When she brought the story back to class, everyone was excited about the better outcome, of course. But what really got our attention was what happened to the relationship.

Pressure changes the conversation

When a stakeholder shows up stressed and already attached to a solution, the conversation can start to feel like an argument. They are pushing for their answer. You are trying to figure out whether that answer makes sense, whether it is feasible, and whether there is a better way to handle it. Even when everyone stays polite, the conversation can turn into a quiet tug of war.

Good questions interrupt that. Instead of debating solutions too early, they move the conversation back toward the situation itself. What happened? What did you notice? What have you tried? What is making this feel urgent now?

That shift matters, not because it is a clever technique, but because it helps both people get out of advocacy mode long enough to look at the same reality. Roger Schwarz calls that mutual curiosity.

In her case, the questions did more than clarify the problem. They also helped her see the pressure this stakeholder was under. He was dealing with leadership scrutiny, an audit finding, and a problem his team had likely been compensating for for a long time. She left with a much better sense of what he was carrying, not just what he had asked for.

There’s usually more going on than the stated request

This pattern applies well beyond Product Owners.

When someone brings you a tense request, they are rarely bringing only the request. They are also carrying concern about how the problem reflects on them, what it means for their team, and how exposed they may feel if it is not handled well. They do not usually say that part out loud, but it still shapes the conversation.

It affects how urgent they sound, how flexible they are, and how quickly they latch onto a preferred solution. It also affects whether the request comes back again next week in a slightly different form.

When you ask about the situation instead of jumping straight to the fix, you are more likely to get to the source of the pressure. That changes what you recommend, what gets built, and often keeps the team from spending time on work that was never going to solve the real problem.

What the class noticed

When this participant told her story, what stood out was not just that she got to a better answer. It was that a conversation that could have turned into another stressful round of solution-pushing ended up giving both people a clearer view of the problem.

He felt heard at a moment when he was under real pressure. She left with more empathy for his situation and a better understanding of what needed to happen next.

The hardest stakeholder conversations, handled well, often do the most to improve the relationship. Not because they go smoothly, or feel comfortable, or because everything gets resolved in the room, but because someone takes the time to sort out what is actually going on before the team charges ahead.

We teach effective techniques for mapping stakeholders and creating a system to stay in touch at the right times. That is an important starting point. It helps you remember who matters, who needs to stay informed, and where attention is needed. But it will not do the most important part for you. That part happens in the conversation itself.

We cover situational interviewing and stakeholder work in our Advanced Product Owner program. It is useful for Product Owners, managers, coaches, and leaders who work closely with them. Sign up below for information on our next cohort!

The post A Better Way to Approach Stakeholder Management appeared first on Humanizing Work.

Leadership is cautiously optimistic, but may be hedging their external commitments, knowing schedules tend to slip out at the end. The experienced people in the org may seem uneasy, quietly waiting for the hammer to drop. They don’t plan vacations towards the end of the release, having been burned too many times by what feels like the inevitable “end game” phase.

And sure enough, the moment integration starts, or deeper system testing begins, or real users touch the system for the first time, we realize things aren’t as rosy as the early status reports indicated. The project goes red. It’s a crisis. Leadership starts getting more heavily involved, bringing additional pressure to get the thing out the door by the committed date. Post mortems usually identify poor planning, undisciplined execution, or teams that couldn’t coordinate and communicate well enough.

While all of that early effort felt productive, the team was busy producing the wrong things. Not because they didn’t plan enough, or weren’t disciplined in their execution, but because the system rewarded the wrong sequence. Predictable work is easy to estimate, easy to staff, easy to put on a timeline, and easy to call progress, so that’s what gets done first. The hard stuff waits.

The Illusion of Foundation-First

There’s a widespread belief in project planning that you have to build those base foundations before you can get to the complex parts. After all, don’t we need to put the infrastructure in place, finalize the specifications for the system’s end state, and ensure the requirements are clear and detailed?

The problem is that the only way to learn about the complex aspects of that initiative is to build and test things in real-world situations. More planning and analysis won’t surface them. The complex parts are emergent—they reveal themselves through contact with reality.

So when teams sequence work to get the foundational pieces in place first, they’re not de-risking the project; they’re delaying learning. Status stays green right up until we get to the complex parts. Doing those last parts causes new information to emerge, and the project plan breaks.

What Emerges Late (but Didn’t Have to)

The things most likely to change your plan are often the things you discover last:

• How the pieces actually work together
• How real users interact with the real system
• How dependencies will impact your team’s work
• How downstream teams like marketing, operations, and finance will support the release

None of these is unusual. They’re the normal complexity of large initiatives. But discovering them as the deadline rapidly approaches snowballs into a project crisis.

Early learning is safe and cheap. Late emergence is risky and expensive.

The Real Fix

The answer isn’t better planning and requirements, more rigorous status tracking, or demanding better estimates from your teams.

The answer is getting to the complex parts sooner—on purpose. That means finding the minimum effective slice of a feature that will force the riskiest integrations to work and put the system in front of real users early enough to actually change the plan.

That’s what Feature Mining, a key move in our CAPED (Complexity-Aware Planning, Estimation, and Delivery) approach, reliably does. Feature Mining cuts through a big, complex initiative to find that first slice—the one that creates real learning about how the pieces fit together and how users will interact with the system, delivered weeks or months before you’d otherwise get there. Check out last week’s newsletter for real examples of Feature Mining doing that for several of our clients.

Go Deeper on April 14

If this pattern sounds familiar, our free webinar on April 14 goes deeper on how to break out of it. We’ll show how CAPED helps organizations stop deferring the key learning and start designing for earlier emergence. Register here.

And if you want to build this capability inside your organization, our Certified CAPED Consultant training runs May 19–22 in person.

The post Why Projects Feel Fine Until They Don’t appeared first on Humanizing Work.

That reaction isn’t unusual. Feature Mining is our collaborative technique for finding the first slice of value & learning through a big initiative. It has a way of turning a room full of skeptical, overloaded people into a group that’s genuinely excited about where to start — and aligned on why. We’ve been running sessions with clients across several industries lately, and we’re seeing this pattern repeat every time.

Here are three recent examples. Details have been changed to protect client confidentiality, but the patterns are real.

Automating Finance Work the Right Way

A CFO asked IT to take a hard look at all their finance processes—find the automation opportunities, figure out where AI makes sense, and free up their people from drudge work so they can focus on more strategic, interesting work. Big ask.

Rather than diving straight into a long planning process, we used the Core Complexity Mapping approach from CAPED (Complexity-Aware Planning, Estimation, and Delivery) with about 60 people from finance and IT, from the CFO down to individual contributors. That cross-level conversation surfaced which processes would benefit most—and gave everyone a shared picture of why. A few pilot processes emerged as clear starting points.

Then we ran Feature Mining sessions with small teams who knew those pilots well. For each one, the session produced a clear MMF (Minimum Marketable Feature) deliverable in weeks, not months. Each MMF would deliver real early value while teaching everyone “the order of the system,” moving later steps into more analytical, plannable territory.

Two things stood out. First, trained CAPED Practitioners led both the Core Complexity Mapping and Feature Mining facilitation. Humanizing Work was in the room, but in a supporting role. That matters because it shows the technique is learnable and transferable, not dependent on any particular facilitator. Second, that leader’s final comment wasn’t just her being polite. It was a genuine, spontaneous expression of excitement after aligning on a breakthrough solution in a little over an hour. That’s what Feature Mining tends to produce.

A Legacy System That Felt Impossible to Replace

An insurance and financial products company has been carrying an aging COBOL-based system for years. That legacy system is deeply tangled with supporting systems, making a full replacement feel almost impossible to do safely. The original plan involved years of work before seeing any real value.

One example of the limitations of that system reminded us of the Y2K problem. For our younger readers, many computer systems in the 1900s only allowed a two digit number to specify the year, and as the century turned, “00” would be interpreted as 1900, not 2000. This would lead to things breaking in a big way. Many NYE parties in 1999 had a “the world might end tomorrow” vibe to them, and consultants were paid big bucks to update old systems to allow a four digit year.

Our client experienced a similar (if less costly) limitation. Some products they wanted to sell literally couldn’t be configured in the old system because of limits on the number of characters in certain fields, hard-coded on the old mainframes.

In a Feature Mining session, the group started generating creative approaches that hadn’t come up before—ways to address core business needs without replacing all the system integrations at once. By the end, they had a path to deliver incremental value much sooner than originally planned, all while learning how the new system should work technically, gathering stakeholder input along the way, and building the political capital needed to see the initiative through.

Years were reduced to months for the first slice.

Getting Sales and Marketing What They’ve Been Waiting For

An IT organization is pulling together data from multiple lines of business into a single CRM, so sales and marketing can finally see individual customer insights and segment views at a glance. Large, complex, lots of stakeholders, lots of pressure.

We started with a pilot Feature Mining session with just the key initiative leaders—a chance to test the technique before opening it up more broadly. That session alone surfaced starting points that could deliver early value rather than waiting several months to show anything.

Based on that result, they invited subject matter experts from the actual sales and marketing teams into a follow-up session. With those voices in the room, even more innovative approaches emerged, ones with real promise to deliver meaningful value significantly sooner than what was originally planned.

What struck us most was the debrief. Leaders expressed genuine gratitude for being brought in this early. One team’s line of business wasn’t selected as the first slice, but they left understanding why another starting point was the smarter business decision, how they’d benefit from the early learning, and feeling like partners in the initiative rather than people waiting to be told what was coming. That kind of alignment is hard to manufacture. Feature Mining tends to create it naturally.

Want to Go Deeper?

Each of these situations involved a complex initiative that felt too big, too risky, or too tangled to know where to start. Feature Mining gives teams a structured way to move from “this is overwhelming” to “here’s exactly what we should build first, and here’s why.”

There are a few ways to take it further, depending on where you are:

• Start for free. The CAPED resources at humanizingwork.com/caped include pointers to Feature Mining guidance from the Humanizing Work Show you can put to work right away. A long-time community member recently shared that they’ve been using that free content to improve how a major Silicon Valley company does discovery—no workshop required to get started.
• Learn it properly. Our self-guided course, 80/20 Product Backlog Refinement, teaches Feature Mining as part of a broader approach to getting the most important work in front of your team. It’s a practical, on-your-own-schedule way to build real skill with the technique.
• Go all in. Our next Certified CAPED Consultant workshop is in May, in person. It’s the best way to build the skills to run Feature Mining and the full CAPED approach for your organization. Or if you’d rather have us come in and facilitate directly, like we did in the examples above, let’s talk.

The post “I Want to Feature Mine Everything Now” appeared first on Humanizing Work.