INSPIRED
Page 4
Risks are tackled up front, rather than at the end. In modern teams, we tackle these risks prior to deciding to build anything. These risks include value risk (whether customers will buy it), usability risk (whether users can figure out how to use it), feasibility risk (whether our engineers can build what we need with the time, skills, and technology we have), and business viability risk (whether this solution also works for the various aspects of our business—sales, marketing, finance, legal, etc.).
Products are defined and designed collaboratively, rather than sequentially. They have finally moved beyond the old model in which a product manager defines requirements, a designer designs a solution that delivers on those requirements, and then engineering implements those requirements, with each person living with the constraints and decisions of the ones that preceded. In strong teams, product, design, and engineering work side by side, in a give‐and‐take way, to come up with technology‐powered solutions that our customers love and that work for our business.
Finally, it's all about solving problems, not implementing features. Conventional product roadmaps are all about output. Strong teams know it's not only about implementing a solution. They must ensure that solution solves the underlying problem. It's about business results.
You will see that I keep these three overarching principles front and center throughout this book.
CHAPTER 8
Key Concepts
In this book, I refer to a set of concepts that form the foundation of modern product work. I'd like to briefly explain them here.
Holistic Product
I have already been using the term product pretty loosely. I did say I'm only talking about technology‐powered products. But, more generally, when I refer to product I mean a very holistic definition of product.
This certainly includes the functionality—the features.
But it also includes the technology that enables this functionality.
It also includes the user experience design that presents this functionality.
And it includes how we monetize this functionality.
It includes how we attract and acquire users and customers.
And it can also include offline experiences as well that are essential to delivering the product's value.
If, for example, your product is an e‐commerce site, then this would include the merchandise‐fulfillment experience and the merchandise‐return experience. In general, for e‐commerce businesses, product includes everything except the actual merchandise being sold.
Similarly, for a media company, we refer to the product as everything except the content.
The point is to have a very inclusive and holistic definition of product. You are not just concerned with implementing features.
Continuous Discovery and Delivery
I explained previously that most companies still have a process that is essentially waterfall at its core, and I told you that what we do in a modern team is very different.
We'll be going more into the product development process later, but I do need to introduce a high‐level concept about process at this point in our discussion. That is, there are two essential high‐level activities in all product teams. We need to discover the product to be built, and we need to deliver that product to market.
FIGURE 8.1 Continuous Discovery and Delivery
Discovery and delivery are our two main activities on a cross‐functional product team, and they are both typically ongoing and in parallel.
There are several ways to think about this and to visualize it, but the concept is fairly simple: We are always working in parallel to both discover the necessary product to be built—which is primarily what the product manager and designer work on every day—while the engineers work to deliver production‐quality product.
Now, as you'll soon see, it's a little more involved than that. For example, the engineers are also helping daily on discovery (and many of the best innovations come from that participation, so this is not a minor point), and the product manager and designer are also helping daily on delivery (mainly to clarify intended behavior). But this is what's going on at a high level.
We need to discover the product to be built, and we need to deliver that product to market.
Product Discovery
Discovery is very much about the intense collaboration of product management, user experience design, and engineering. In discovery, we are tackling the various risks before we write even one line of production software.
The purpose of product discovery is to quickly separate the good ideas from the bad. The output of product discovery is a validated product backlog.
Specifically, this means getting answers to four critical questions:
Will the user buy this (or choose to use it)?
Can the user figure out how to use this?
Can our engineers build this?
Can our stakeholders support this?
Prototypes
Product discovery involves running a series of very quick experiments, and to do these experiments quickly and inexpensively, we use prototypes rather than products. At this point, let me just say that there are several types of prototypes, each for different risks and situations, but they all require at least an order of magnitude of less time and effort than building a product.
To set your expectations, strong teams normally test many product ideas each week—on the order of 10 to 20 or more per week.
To set your expectations, strong teams normally test many product ideas each week—on the order of 10 to 20 or more per week.
I want to emphasize that these are experiments, typically run using prototypes. A prototype is not something that's ready for prime time and certainly not something your company would try to sell and stand behind. But they're immensely useful, as they're all about learning fast and cheap.
Product Delivery
The purpose of all these prototypes and experiments in discovery is to quickly come up with something that provides some evidence it is worth building and that we can then deliver to our customers.
This means the necessary scale, performance, reliability, fault tolerance, security, privacy, internationalization, and localization have been performed, and the product works as advertised.
The purpose of product delivery is to build and deliver these production‐quality technology products, something you can sell and run a business on.
Products and Product/Market Fit
Just because we've invested the time and effort to create a robust product does not mean anyone will want to buy it. So, in the product world, we strive to achieve product/market fit.
This is the smallest possible actual product that meets the needs of a specific market of customers. Marc Andreessen is credited with popularizing this all‐important concept, and it is a major focus of this book.
And just to be clear, since these are actual products, they are the result of delivery. The discovery activities help us determine the necessary product, but it is delivery that actually does the work necessary to build, test, and release the product.
Product Vision
The final critical concept is product vision. This refers to the longer‐term objective of this product, normally 2–10 years out. It is how we as a product organization intend to deliver on the company's mission.
So, we use prototypes to conduct rapid experiments in product discovery, and then in delivery, we build and release products in hopes of achieving product/market fit, which is a key step on the way to delivering on the company's product vision.
Now don't worry if you're hazy on any of these concepts. I know you likely have many questions, but they'll hopefully become clear as we dive deeper into each topic. It's also normal to be a little skeptical—“How can I possibly run 15 of these experiments in a week?”
I warned you that strong product teams work nothing like most teams, and this should give you your first taste of how different things can be.
Minimum Viable Product
The conc
ept of minimum viable product (MVP) is one of the most important concepts in the product world. It has been around for many years. The term was coined by Frank Robinson (in 2001), and I wrote about the concept in the first edition of this book (in 2008). It was popularized, however, in the book The Lean Startup by Eric Ries in 2011.
Eric's book did a great deal to help product teams, and to me, it is a must‐read book for all product people. But I think most people would likely admit that the concept of MVP has caused considerable confusion within product teams, and I spend a lot of my time helping teams get value out of this critical concept.
The vast majority of times I meet a team that has been working hard to create an MVP I am able to convince them that they could have achieved the same learning in a fraction of the time and effort. They have spent literally months building an MVP when they could have had this same learning in days or, sometimes, even in hours.
The other unhappy consequence is that very often the rest of the company—especially key leadership in sales and marketing—is confused and embarrassed by what the product team is trying to get customers to buy and use.
While this is partly a result of the way most people have learned this concept, I think the root of the issue is that while the P in MVP stands for product, an MVP should never be an actual product (where product is defined as something that your developers can release with confidence, that your customers can run their business on, and that you can sell and support).
The MVP should be a prototype, not a product.
Building an actual product‐quality deliverable to learn, even if that deliverable has minimal functionality, leads to substantial waste of time and money, which of course is the antithesis of Lean.
I find that using the more general term prototype makes this critical point clear to the product team, the company, and the prospective customers.
So, in this book, I talk about different types of prototypes being used in discovery and products being produced in delivery.
PART II
The Right People
Every product begins with the people on the cross‐functional product team. How you define the roles, and the people you select to staff the team, will very likely prove to be a determining factor in its success or failure.
This is an area in which many companies fall short, stuck in old models of the past. For many organizations, the roles and responsibilities discussed here represent significant differences from what they're used to.
In Part Two, I describe the key roles and responsibilities of modern technology‐powered product teams.
Product Teams
Overview
This is probably the most important concept in this entire book:
It's all about the product team.
You'll hear me say this many different ways throughout the chapters to follow, but so much of what we do in a strong product organization is to optimize for the effectiveness of product teams.
CHAPTER 9
Principles of Strong Product Teams
In later chapters, I explore each of the key roles on a team, but in this chapter, I explain the principles of a strong product team.
Product teams are sometimes referred to as a dedicated product team or as a durable product team, to emphasize that these are not created just to work on a single project or feature, or sometimes as a squad—derived from the military analogy and meant to emphasize that these are cross‐functional teams.
A product team is a group of people who bring together different specialized skills and responsibilities and feel real ownership for a product or at least a substantial piece of a larger product.
There are many ways to set up product teams (we'll discuss these later in the section People @ Scale). But in good product companies, you'll find that, despite the differences due to their unique products and circumstances, there are several very important similarities.
Team of Missionaries
There are many benefits of product teams, but a big goal is captured best by a quote from John Doerr, the famous Silicon Valley venture capitalist: “We need teams of missionaries, not teams of mercenaries.”
Mercenaries build whatever they're told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers. In a dedicated product team, the team acts and feels a lot like a startup within the larger company, and that's very much the intention.
We need teams of missionaries, not teams of mercenaries.
Team Composition
A typical product team is comprised of a product manager, a product designer, and somewhere between two and about 10 to 12 engineers.
Of course, if the product you're working on doesn't have a user‐facing experience—such as for a set of programmatic APIs—you probably don't need the product designer. But many product teams do need this person on board, and throughout this book, I'll generally assume your team does, too.
Teams might also have a few other members such as a product marketing manager, one or more test automation engineers, a user researcher, a data analyst, and, in larger product organizations, a delivery manager.
Don't worry if you don't yet know what some of these roles are—we'll soon explore each of them.
Team Empowerment and Accountability
A big part of the concept of product teams is that they are there to solve hard problems for the business. They are given clear objectives, and they own delivering on those objectives.
They are empowered to figure out the best way to meet those objectives, and they are accountable for the results.
Team Size
There's no rule that says all product teams in a company need to be the same size. It's true there is the notion of critical mass for a product team—usually one product manager, one designer, and two engineers. However, some teams might justify five engineers and two test automation engineers—others even more.
There is a practical upper bound on a team, which usually works out to be around 8–12 engineers. You've probably heard about the two‐pizza rule, which is intended to help keep teams in this range.
More important than the absolute size of the team is the balance of skills needed to ensure we build the right things, and build those things right.
Team Reporting Structure
Note that I haven't said anything yet about who works for whom.
A product team is not about reporting relationships—it has an intentionally flat organizational structure. Usually, everyone on a product team is an individual contributor, and there are no people managers.
The people on the team typically continue to report to their functional manager. For example, the engineers report to an engineering manager. Likewise, the designer usually reports to a head of design, and the product manager reports into a head of product. So, this is not about reporting relationships.
To be absolutely clear, the product manager is not the boss of anyone on the product team.
Team Collaboration
A product team is a set of highly skilled people who come together for an extended period of time to solve hard business problems.
The nature of the relationship is more about true collaboration. I don't mean collaboration as a buzzword, either. I literally mean product, design, and engineering working out solutions together. Much more on that to come, but at this point, it's important for you to understand that this is not a hierarchy.
Team Location
I also haven't said anything yet about where the members of the team are physically located. While this isn't always possible, we try very hard to co‐locate this team.
Co‐location means that team members literally sit right next to one another. That doesn't mean in the same building or even the same floor. It means close enough to easily see each other's computer screens.
I know this sounds a bit old school, and the tools for remote collaboration are getting better all the time, but the best companies have learned the value of sitting together as a team.
If you've ever been a member of a co‐located product team, you likely already know what I mean. But, as you'll see from how we do our work on a product team, there is a special dynamic that occurs when the team sits together, eats lunch together, and builds personal relationships with one another.
I'm aware this can be a bit of an emotional topic. For personal reasons, quite a few people live somewhere other than where they work, and their livelihood depends on working effectively remotely.
I don't want to paint this as too black or white, but I also don't want to mislead you. All other things being equal, a co‐located team is going to substantially outperform a dispersed team. That's just the way it is.
This is also one of the reasons why we greatly prefer members of a product team to be actual employees and not contractors or agencies. It's much easier to be co‐located and to be a stable member of the team if the person is an employee.
Note that there is nothing wrong with a company having multiple locations, so long as we try hard to have co‐located teams in each location.
We'll talk later about what we do when not all the members are able to sit together.
Team Scope
Once you've got the basics of a product team, the next big question is this: What is the scope or charter of each team? That is, what is each team responsible for?