In his book Inspired: How to Create Products Customers Love (SVPG Press), Marty Cagan describes the responsibility of a product manager to identify a product that’s valuable, usable, and feasible. When I first read these words, I pictured in my head a simple Venn diagram where the solution we want is an intersection of what’s valuable to our company and our customers, usable by its users, and feasible to build given the time and the tools we have.

But what may not be dead obvious here is that, to really identify the solution in the center of that sweet spot will take collaboration between people who understand our business, our customers, our users, and the technology we use—and not just understand those things, but take responsibility for the success of the solution. These people actually speak with stakeholders, customers, and users; they actually design and test user interfaces; they actually design and test the code that makes the product work.

Remember that misconception in Agile development where a single product owner or product manager decides what to build? It’s rare if not impossible for a single person to possess the business, user interface design, and engineering skills necessary to find that valuable-usable-feasible sweet spot. That’s why the most effective organizations use small, cross-functional discovery teams that work together to find that right solution. As we discussed in the preceding chapter, think of discovery as rock-breaking work. It’s the work we do to move a story from a big vague idea to something small and specific we can build.

The ideal size for the team is two to four people—dinner-conversation-sized so the members can quickly build shared understanding.

This team should be led by a product owner or product manager who has deep understanding of her business’s vision and strategy, and of the market her product serves. This core team includes someone who understands users, is comfortable working with them to learn about the way they work, and can sketch and create simple UI prototypes. It also includes a senior engineer from the team who’ll build the product. This person needs to understand the current architecture of the system and have insight into newer engineering approaches that could be used to solve tough problems. The real secret here is that the most innovative solutions often come from the engineer supplied with insight about the business problem and the users’ problems.

A cohesive discovery team is a powerful, fast-moving group of experts who can find problems and validate solutions quickly. I often hear the term triad used to describe this core team. On my recent visit to Sydney-based Atlassian, Sherif, whom you met in Chapter 8, pointed to three seats close together. He explained, “This is where the triad sits.” The area around the triad was filled with desks and computers where the rest of the team sat. I hear the term triad used when there are two people, four people, or even more on the discovery team, since it’s the three concerns—valuable, usable, and feasible—we’re talking about, not three bodies.

An effective discovery coordinates collaboration with not only the development team, but also business stakeholders, subject matter experts, customers, and end users. It’s tough work that requires top-notch communication and facilitation skills, in addition to the specific expertise each team member brings in.

Now, here’s the real secret. For a product of any significance, it’ll take a team to get it built. To keep the vision of the product clear, ensure the solution the team builds is cohesive, and help keep everyone moving in the same direction, a good product leader is critical. The best of these leaders focus on helping everyone take ownership. In a healthy story-driven environment, you’ll see lots of story conversations going on all the time. And many of them won’t need the product leader there.

¡Three Amigos! is the name of a mediocre 1986 western comedy starring Steve Martin, Chevy Chase, and Martin Short. What does this film have to do with Agile software development and stories? There’s a more tactical triad of collaborators that’s valuable during story workshops. And I’m not sure who originally gave them the moniker “the three amigos,” but it appears to have stuck.^[13] (I’m sure if more people had seen the movie, it wouldn’t have.)

You might recall that story workshops is the term I give to that last best conversation where we decide specifically what to build. It’s here where the three amigos come in.

During this last best conversation, we really need to consider lots of details and alternatives for implementation, so we’ll need a developer from the team who’ll build the software—ideally, one of the developers who will actually work on it.

For this small piece of software to be considered done, it’ll need to be tested, so we’ll need a tester in the conversation. A tester—the first amigo—will often bring a critical eye into the discussion, spotting things that might go wrong sooner than most. The tester is often the best at playing the “What-About” game.

And, of course, we’ll need someone who understands what we’re building, who it’s for, and why we’re building it, so we’ll need a member of that core product discovery team. That person is the second amigo.

At this stage we’re often not introducing a new feature idea. We likely already did that back in discovery. Now we’ve more or less committed to build something, so it’s important to understand specifically how that software should look and behave. So often the person involved in this conversation is a user experience designer or business analyst who’s worked through those details. This is your third amigo.

This group will work through the details and agree on specific acceptance criteria for the story. It’s out of this conversation that we’ll have our best estimate of how long it will take to build and test the software. And it’s often in this conversation that we’ll make decisions to split the story into smaller, “right-sized” development stories—those stories that take one to three days to build and test.

Story conversations happen continuously as we move ideas through software development. In every conversation, keep what’s valuable, what’s usable, and what’s feasible in the discussion. Include people who can speak to those things. Avoid design by committee by holding a product owner responsible for a successful, cohesive product.

The Client-Vendor Anti-Pattern

There’s a nasty anti-pattern that gets in the way of using stories well. In fact, it can get in the way of people working together to do anything well. It’s the dreaded client-vendor anti-pattern.

In this anti-pattern, one person in a conversation takes the client role, while the other takes the vendor role. It’s the client’s job to know what he wants, and to explain the details to the vendor. That’s what we call “requirements.” It’s the vendor’s job to listen, understand, and then think through a technical approach for delivering what the client asked for. The vendor then gives her estimate—which in software lingo actually means “commitment,” and is the reason why developers often fear giving estimates without thorough investigation.

The rest of the story is sadly predictable.

Every once in a while, the estimate is deadly accurate, and the client gets what he wanted, and what he wanted actually turns out to be what he needs.

But, most of the time, constructing a solution takes longer than the vendor predicted. The person in the vendor role can cite all sorts of excuses for the delay, including lack of details in the requirements she was given, or just “bad requirements.” The client can blame inaccurate estimation—which no one seems to notice is an oxymoron. When the solution is delivered, and the person in the client role receives what he asked for, he then gets an opportunity to use it and realize it’s not what he needs. He doesn’t get the outcome he imagined he would.

The real tragedy here is that the person in the client role understands his problem better than he’s able to predict what will solve it. And the person who understands the technology is often the most qualified to solve the problem because she knows how the technology she’s working with can help. What’s more, most technologists honestly want to help. They want to know the things they’re building are put to good use.

But, in the client-vendor anti-pattern, conversations about problems and solutions are replaced by discussions and agreements about requirements. No one wins.

One of the goals of stories is to break this anti-pattern.

One kind of relationship many of us have that does break this anti-pattern when it goes well is the one we have with our doctor. Try showing up at your doctor’s office and giving her your “requirements.” Tell her the prescriptions you’d like written and the operations you’d like scheduled. If she’s nice, she’ll smile and say, “That’s interesting; tell me where it hurts.”

In my head, I picture a continuum where on one side is the word waiter, and on the other is the word doctor. Try to make your working relationships much more like a good doctor-patient relationship, and much less like a waiter-diner’s.

If you work in a more traditional IT setting, the notion of a product owner may seem confusing. For example, if you help build critical systems for a bank, the bank knows its real products are the banking services it sells to its customers. If there is a person with the official title of “product manager,” it’ll be his job to look after a specific type of bank account or credit product. The computer systems that support that service offering are just a piece of the puzzle. And often that same IT infrastructure supports lots of different banking products. Understandably, the bank doesn’t see that infrastructure as a product, and there’s often no one who owns it.

In these types of organizations, business analysts (BAs) are often placed in a “requirements gathering” role. They’ll act as an intermediary between the developers and the business stakeholders like the product manager of a banking or insurance product. When those businesspeople need changes to the IT infrastructure that supports their product, they’ll work with the BA to describe those changes. And here’s where they might take on the client role as the BA acts in a vendor role, and that’s where the anti-pattern kicks in.

In casual conversation, my friend David Hussman gave me a better metaphor for the relationship the BA should have with his business stakeholders—the same relationship that a music producer has with a band. This makes sense coming from David, who’s both an Agile guru and ex-guitarist for the 1980s heavy metal band Slave Raider. He’s worked with producers, and been a producer himself. In that relationship the band comes to the music business with passion, and hopefully some talent, but they don’t know the music business or the mechanics of recording an album. The producer does, however. It’s the producer’s job to help that band make the most successful recording it can. Successful producers can turn raw talent into a polished, commercially viable recording artist.

As a business analyst in an IT context, that’s your job. Take the vision of your business stakeholders and help them make it a success. You can’t be just an order taker—you’ll need to behave more like a doctor. And sometimes this means telling your stakeholders things they don’t want to hear. But, if you’re sincere about helping them succeed, they’ll see it and value your help.

One potential anti-pattern is to make the business stakeholder take on the product ownership role. I say potential because it can work if the businessperson has lots of help and support from other team members, an aspiration to learn how to do the job of a product owner, and the time it’ll take to do it. Product ownership isn’t a trivial responsibility, and shouldn’t be treated as something that could be done in your spare time. Instead of forcing another job on businesspeople, I’d recommend you find them a producer to help them succeed.

For an idea that at its core is simple, this whole story thing has gotten terribly messy. If anyone told you software development—or any product development, for that matter—was easy, they were lying.

Stories are many things at once. We’ll use the word to refer to the card, to the chunk of software we build, and especially to the kind of conversations we have to make decisions about what we should build. Stories can describe very large opportunities, or the almost insignificant deliverable pieces that by themselves aren’t necessarily meaningful to customers and users. Working with stories is a continuous process of conversation and discussion to break them down from big things to small things. And through all those conversations, we’re keeping not only what we could build in focus, but for whom, and why. Story mapping is just one of the ways to help us break big things down while keeping the focus of the conversation on the people using your product and what makes them successful.

If this is all starting to make sense, then you’ve made that big, necessary mindshift. It’s not a shift to use stories to document requirements, but a shift toward working with people more effectively, and together focusing on solving real problems with the products you create.

And that, I hope you’ll agree, is a beautiful thing.