In The Loop—Chapter 13: Product Discovery vs. Product Management

21 min read

In the fit systems enterprise it’s all about systems. In the next seven chapters, we dive into the operating systems and meta systems.

Great companies become great because of their extraordinary products. Products are created and improved within company systems. How do you create and maintain a product? You choose a customer segment, and focus on needs. You discover product solutions that meet these needs. You build the product. You deploy it, and leverage signals of purchase and use to continuously improve it. You conduct product marketing. This is the world of product management. One system, right?

The In The Loop leader says, “not so quick.” As a systems thinker, you know that a system’s boundary has integrity when a preponderance of work occurs inside its edges, pursuing a unique purpose. System contours shape how you will lead, and how people in your company will think and act. Purpose is the arbiter of system boundaries. When you look closer, it becomes clear that in the product arena there are five purposes, each associated with a separate system:

  • Create new products delivering new value breakthroughs for targeted customers (the product discovery system)
  • Improve current products with value optimizations for existing customers (the product management system)
  • Provide product and engineering teams the tools, agile methods, reference architectures, frameworks and infrastructure to build digital products in a way that increases technology resilience, scalability and efficiency (the engineering system)
  • Provide product and engineering teams the necessary data schemas, data flows, infrastructure and tools to democratize data access for domain teams and support a data driven culture so that products can be continuously improved (the DataOps system)
  • Acquire and retain customers who use the product, growing revenue while operating within the constraints of unit economics (the revenue engine system)

The product discovery system stands apart from the other systems because it operates from an extreme outside-in posture, independent of the “going concerns” of the enterprise. Only after a value breakthrough has been discovered does the new product move into the product management system and become part of the company’s growth engine.

Product discovery teams must immerse themselves in the marketplace and inside the customer’s obstacles and pain points. There is no existing product, so there is no direct data on feature usage or churn rate or net promoter score. All you have is your observations, and the reactions of targeted customers when you ask, “how valuable would it be if I built this?”.

The product management system, on the other hand, operates to improve existing products. Data streams in every day, from customer support tickets to internal conversion data to feature usage data and churn. Teams immerse themselves in the data and seek to continuously improve the product by pursuing business outcome objectives.

The revenue engine system impacts product in three ways:

  • The prospect’s pre-purchase product experience
  • Brand identity
  • Pricing

In my first book, Scaling the Revenue Engine, I discussed the power of creating a “sales ready product.” This is a product that is built to seamlessly move the prospect from the moment of first product experience, to the moment of initial pre-purchase value. The freemium model is one example of a sales ready product. In this model the prospect can use the product up to some use threshold for free. Another variation is “free trial”. Sales ready products are designed to deliver a highly intuitive digital user experience to the pre-customer with rapid discovery of value. The premise is that if a prospect can find your product, test it and experience rapid value discovery, customer acquisition will be more successful.

The second connection point between the revenue engine system and the product discovery and product management systems is brand identity — as expressed in value proposition, competitive positioning and visual design. Brand identity must be consistently expressed, both within the product and throughout all external messaging. The third connection point is pricing. The value you create and the value you capture (through pricing) are, of course, closely correlated.

In this chapter, our focus will be on the product discovery system and the product management system. These two systems sound similar to each other. Why think of them as separate systems?

Both require outside-in thinking and iteration towards truth. But there is an order of magnitude difference in degree. At the outset of product discovery, every notion of the product’s customer-perceived value is just a hypothesis. There is no proof. Early on, the product discovery system must struggle through a high-variation phase where hypotheses are rapidly and iteratively tested, narrowing slowly towards truth. Only after sustained customer immersion, hypothesis testing and rapid prototyping may clarity emerge.

With the product management system, on the other hand, a product already exists. You have visibility into the features that deliver the most value today, and where the gaps may be. This clarity helps you zone in more quickly on points of value optimization. As you execute the fix, finish and fill work of product management it’s still important to approach problems with an outside-in, rapid prototyping approach. But you have a starting point.

A Story

My life changed the day in 2006 that a friend, the General Manager of Toyota Sunnyvale, approached me. “I’ve got problems in my internet department,” he said. “I think there might be a business opportunity.” After four months of discussions, we each wrote checks for $100,000 and ResponseLogix (later named Digital Air Strike) was born. I set up shop in Toyota Sunnyvale’s small second floor conference room. Thus began a six year journey of hardship, discovery, growth, good decisions and bad decisions that eventually yielded a moderately successful startup.

But I want to take you back to the beginning. At inception, we only had a vague idea that auto dealer internet departments were screwing up how they handled prospect leads. Industry data showed that a third of all auto internet leads were not answered at all, and the average response time was over six hours. But why?

It was eye opening to sit right next to the ten-person internet department at Toyota Sunnyvale. Watching and learning, we began to see the problems. Prospect lead volume was lumpy. Some days were dead as doornails. Other days were super busy. On the busy days, time and again sales reps would be drawn away from their desks to serve customers arriving at the store. The CRM system could route leads to available reps, but whenever the volume of incoming leads exceeded available rep capacity, everything broke down. Back at his desk and confronting seven leads in the CRM queue, a rep would work from the most recent lead back, figuring (correctly) that the older leads would be less likely to close. Older leads routinely fell through the cracks, going entirely unanswered.

We learned that most auto dealer CRM systems could execute responses to consumers automatically, but these responses were boilerplate: “Thanks for your interest in Toyota Sunnyvale. A sales representative will reach out to you soon.” They failed to address the customer’s most common questions: “do you have ‘x’ in stock”, and “what’s the price”. We knew the consumer hadn’t reached out to just one dealership. Many were in play, simultaneously. All else being equal, speed and transparency won out. They wanted to know the price and availability of their vehicle of choice, and wanted to engage. We theorized that the dealer with first mover advantage would gain increased sales.

We learned it was actually quite difficult — impossible, we first thought — to determine at any given moment the status of vehicles in stock (in all their make / model / trim permutations), the status of manufacturer incentives (which changed every month) and the proper price of a vehicle, given the dealer’s pricing rules.

So we played around with all kinds of ideas for improved initial responses. We thought of building centralized call centers that could serve multiple auto dealerships, but realized it would be a logistical nightmare (and we didn’t want to be in a “talking heads” business). We played around with all kinds of response template designs; they all did a better job of saying nothing. We thought we knew the technical limitations of dealerships, so we didn’t seriously consider trying to actually share the real price of a car in stock — until a top exec from Toyota happened to visit the store. Upon hearing about our efforts he cut right to the heart of it. “They want the price. Want to create something new? Get them the price.”

This guidance was helpful, but the technical challenge was daunting and our cash was insufficient to crack this big technical and data problem with software. Furthermore, we didn’t have any proof that a rapid price quote would have a direct impact on the number of cars a dealer could sell per month. Could a fast, accurate price quote yield higher conversion? We needed the answer before spending our precious cash on software development.

So we started by executing the quotes manually. We recruited a small group of “quoters” and used the dealer’s own CRM system. Every time a lead came in, we would manually go into the dealer’s vehicle inventory system to check on availability. We would then check current manufacturer incentives and the dealer’s pricing rules for the vehicle in question. And then we would manually hack the CRM’s boilerplate tool to create a customized price quote referencing the car the consumer was asking about. The whole process took about 10 minutes per quote. It was messy, but to the consumer it looked like a custom response from a real sales rep.

At first, we only executed these quotes at Toyota Sunnyvale. On the first day we went live, sales reps immediately reported back that the quotes were causing the quality of phone conversations to rise. The quotes created trust. After three months, the data showed that the conversion rate from leads into appointments was rising. Soon after, we learned that the conversion rate from appointments to sales was also higher. We had our proof: a rapid, accurate price quote increases sales.

At that point, we started to charge for our service. We charged based on quote volume. Four other dealerships signed up for our lead response / quoting service. As our six-person quoting team began serving these other dealerships, sales rose there as well. Behind the curtain, of course, we were a chaotic, disorganized mess. Technical difficulties arose as we tried to remotely access and hack multiple auto dealer CRM and vehicle inventory systems. The duck looked like it was smiling, but under the water it was paddling like crazy just to stay in place.

Eventually, we gained confidence rapid price quotes on a vehicle of interest could consistently drive a meaningful improvement in dealer sales. So we raised a seed round and built software that could automate the quoting process. It was technically quite difficult — in fact, some of the technical challenges were never fully solved — but we did keep raising money, and we scaled over six years to about $20M in revenue and 2000 auto dealer customers. We iterated continuously on the minimum viable product (MVP) based on feedback. Eventually our quotes featured not just the vehicle the consumer asked about, but new and used alternatives. Sent “from” the assigned sales rep to the consumer within five minutes of receiving the lead, our quotes drove solid sales performance improvements for customers. In time, we developed a diversified product line that addressed multiple stages of the dealer-to-consumer messaging continuum.

Looking back, I actually believe the steps we took to uncover MVP were the actions of a healthy product discovery system. We made many mistakes later in our scaling journey, but our first moves were spot on. By living inside an auto dealership for a year and a half, we immersed ourselves in our customer’s reality. That helped us to ideate and iterate our way towards a true value breakthrough much faster than would otherwise have been possible. And we didn’t rush too quickly to develop software. We kept everything manual until we were pretty sure our value thesis was proven and the product poised for success.


By differentiating product discovery from product management, we shine one spotlight on new product value breakthroughs and another on existing product value optimizations. Large enterprises often mistake product management for product discovery. They think that because they are responsive to the needs of customers, taking them into account in continuous product improvements, they are fulfilling their generative mission. But because its focus is only on existing customers of your existing product, the product management system is not designed to detect the voices of not-yet-customers. Nor can the product management system, acting alone, exhibit the peripheral vision and game-changing innovative leaps that happen when you operate a healthy product discovery system.

In the world of large enterprises the product discovery system is key to relevance and survival. Over the years, many such enterprises have slid slowly into the abyss due to atrophy in their product discovery systems. They scaled up for years, milking some big value breakthrough from long ago until the milk ran dry. Suddenly the market shifts, and they don’t — and it kills them.

The Product Discovery System

Market truth is in motion. An effective product discovery system is designed accordingly. At regular intervals in the scaling of a company, a new value breakthrough is needed. It then becomes necessary to reactivate the product discovery system. At scale in the fit systems enterprise, your product discovery system should run continuously, through the work of multiple simultaneous innovation experiment teams. If it is run well, the system will deliver a slow drumbeat of value breakthroughs that propel continuous growth. Breakthroughs become new products, which offset the inevitable decline of older, more mature products.

The product discovery system works to advance the generative imperative through the principle of “wide outside in.” It tests fit between product concepts and persona needs. A cycle of hypothesis creation, testing, iteration and optimization warps and woofs over time in response to market dynamics.

Innovation lives at the intersection between human need and product capability. Most successful companies are built on the foundation of one of two types of product discovery breakthroughs:

  • High technical risk / low market risk (examples: Edison’s light bulb in 1878; Google’s autonomous vehicle project)
  • Low technical risk / high market risk (examples: CBS Radio in 1927; Facebook)

These two types of product discovery are different. For the first, less work needs to be done to confirm product / market fit. It was self-evident that if a light bulb could be invented, there would be strong market demand. The same could be said about a safe autonomous vehicle. For the second type of innovation, much more work must be done to confirm product / market fit. In fact, the technical challenge is relatively low — solving for the market risk is everything. The second radio network (CBS), or Facebook, or AirBnB, or most of today’s media, ecommerce and B2B SaaS products are all examples of this second type of innovation.

Our focus in this chapter is on the second — low technical risk / high market risk.

A healthy product discovery system exhibits some important characteristics. It is customer centric. It is human centric — uniquely focused on the needs and experience of each relevant persona. Empathetic listeners immerse themselves in the customer’s world and jobs to be done. It is a system that rests comfortably in ambiguity. It defies timelines and predictions.

While the dominant feature of the product discovery system is wide variation and continuous iteration down a narrowing path, at a high level there are eight discrete steps in the system’s workflow:

  • Immersion and ideation
  • Epiphanies
  • Hypothesis definition
  • Hypothesis testing and validation
  • Rapid prototyping
  • Design validation
  • Build and release initial product
  • Complete minimum viable product

Here they are, with their stocks, flows and the high level feedback loops:

Including its people, workflows, technology and money flows, the product discovery system (for a single team) looks like this:

Of course, in a large enterprise multiple innovation teams are likely to be simultaneously at work seeking new product value breakthroughs. Each team is an independent domain team, like this:

In Chapter 7 I shared how small, autonomous, cross-functional teams can create superior system performance and increase system resilience. This is especially true in the product discovery system. The mission is a value breakthrough. As CEO, it’s your job to fund the innovation project, bring together a team capable of making it happen, provide the team a business outcome objective and step out of the way.

What is the right team composition? In the beginning, a product discovery innovation team should start with a product manager (with strong domain and technical expertise), a designer, and an engineering lead. Depending on the product, a user experience researcher and data analyst may also be required. If you can, include one or more visionary customers as well. They will keep you thinking outside in. As early ideation and hypothesis testing moves into rapid prototyping, you’ll need more engineers. As discovery moves into development of the MVP, team size may rise to 10–12 people. If you are the CEO of a six month old company, you’re on this team. If you’re at enterprise scale, you might have twenty separate teams working in parallel on different product discovery initiatives.

Ground the team in the company’s mission, product vision and the broad team purpose — the business outcomes you hope to achieve. Put the focus on business outcomes, not a defined product solution. Check in only occasionally for progress updates. Autonomy creates ownership. A strong product discovery team will discover the most important customer jobs to be done, ideate ways to do them better and iterate towards the right product solutions. The best product experiences and most thoughtful technical designs come from autonomous teams.

A critical success factor in this system is pace. The faster you can spin the hypothesize / test / iterate flywheel, the faster you will vector in on truth.

Let’s go through each step in the team’s workflow.

Immersion and Ideation

This first step is the most common failure point in an underperforming product discovery system. Too many companies seeking a value breakthrough underinvest in this step. Immerse! Live in the market, with the customer, with the problem. The feedback loops are all around you. Get comfortable with ambiguity. Connect deeply and empathically with the humans occupying “target customer personas”. What jobs are they seeking to accomplish? What barriers stand in the way? How big a difference would it make to people and companies if the job to be done was made massively easier, or if it became fully automated?

As you immerse and explore, the jobs to be done will surface in front of you. You will begin to conceive of ways to make these jobs easier. At this stage, your mission is to create a wide array of alternative job-improving ideas. Through doing the job yourself, interviewing people who do the job, studying people doing the job and matching those experiences against what you know (in terms of technology capability, workflow insights, domain knowledge or whatever other relevant capabilities you bring), ideas will emerge. This creative process is often intuitive. You generate many ideas, and you expose them to the people in your chosen market and segments of interest. Their reactions cause you to iterate. One idea sparks the next. Almost all of your ideas “fail” or are “wrong”, but from each “failure” you learn something that helps you narrow incrementally towards truth.

Epiphanies

Somewhere along the way you begin to sense that you are closing in on something important. It may come in a flash of insight, or it may be a slow dawning conviction. These are epiphanies. An epiphany is pre-rational. It’s a “gut instinct”. But it’s an important step in the process. Great innovators don’t proceed without them. Many people searching for a value breakthrough seek to approach the entire process analytically, and as such they undervalue and distrust epiphanies. They prefer to live only in the world of data and science. But an epiphany is in the world of science. It is the starting point for a hypothesis, the first step in the scientific method. Trust your gut, and be open to your epiphanies.

Hypotheses

Epiphany in hand, you must now shift your mental mindset from pre-rational to rational. It’s time to express your epiphany as a hypothesis. In fact, as Steve Blank noted in his book “Four Steps to the Epiphany”, multiple hypotheses are required:

  • Customer hypothesis — customer segmentation scheme, personas, jobs to be done, pain points for each persona, value of solving the pain
  • Product hypothesis — how the product as you conceive it will improve the job to be done and solve the pain such that it delivers at least 10X improvement versus current solutions
  • Market hypothesis — confirmation that there are enough relevant companies or consumers who conduct these jobs or experience these pain points that you could build a public company to serve them
  • Competitor hypothesis — an assessment of the competitive set, and the degree to which the pain points to be solved are already being solved by existing companies as compared to your proposed product
  • Pricing hypothesis — given the ROI or value that the product delivers, the estimated demand curve and proposed price points (including expansion pricing)
  • Revenue engine hypothesis — given the expected LTV of the product, the profitable means by which you plan to acquire, retain and expand customers

Hypothesis Validation

Now you’re ready to return to the market, back into the customer’s milieu. Every claim within the six hypotheses needs to be challenged and critically evaluated through deep customer engagement. The voice of the customer, as expressed in personas, is paramount. Here it is helpful to leverage both formal research and anecdotal insights. Test your hypothesis claims with as many target customers as you can. As you iterate on the hypothesis, see if you can recruit and select a customer feedback group that fits your defined target market. These should be folks willing to spend time with you on hypothesis refinement, prototype testing and review. This feedback group will help you further refine the six hypotheses to the point where you are ready to develop prototypes.

Rapid Prototyping

Having reacted to your initial hypotheses, the customer feedback group is now ready to critically review and comment on prototypes. As you create a prototype that matches the product hypothesis, garner reactions. Leverage feedback to create the next prototype. It’s not unheard of for teams to execute five prototypes a week, constantly iterating. Prototypes are often created and shared in paper form, or with light wireframes created within online tools. The job of the prototype is to convey the essential product features that address the customer’s job to be done as described in the product hypothesis, with the minimum possible design time. Keeping prototype creation fast and easy is key to frequent iteration. As the customer feedback group provides input, you will iterate the prototypes and their underlying hypotheses — hopefully on a narrowing path.

If your product is deeply technical, it’s different. Prototyping is focused on creating a product that can do the intended job. It can take months or years to solve hard technical problems. For these types of problems, your build / test / learn / iterate cycle will not involve human feedback so much as technical performance. Edison’s light bulb didn’t work until it did.

Design Validation

Once you have identified a prototype that appears to address the customer’s job to be done, it’s time to fill out the prototype — developing the visual design, the copy and content and the user experience workflows. As the prototype fills out, expand the customer feedback circle. If there were ten participants in your initial customer feedback group, find thirty or fifty more. The more reactions you receive, the higher quality the signal. Iterate, iterate, iterate. Then iterate again.

Initial Product Release

CBS was the second radio network in the US, after NBC. As such, the technical risk was low. The greater risk to be overcome was a market risk. William Paley built CBS into a powerhouse because he had an uncanny sense for popular tastes in programming, was committed to a strong advertising-based business model, and was able to assemble a large enough network to be interesting to advertisers. The technology was already solved. The problem he needed to solve was the market problem.

More recently, Facebook expanded from a Harvard-only social networking site to become the world’s dominant social platform by capitalizing on an emerging thirst for social interactions online through a safe, selective and well designed user experience. Facebook initially only served students — you had to have a .edu email address. That kept its user base young, which helped with its brand identity. Especially early on, nothing about its technology was cutting edge. The breakthrough was in the market insight. For CBS and Facebook, the value breakthrough was overcoming high market risk.

Initial product release (IPR) is achieved when you first make your platform or solution available to customers for use or purchase. For CBS, it was when the first radio network was launched in 1927 (it failed, and the company was bought by Paley). For Facebook, it was the launch of the first website at Harvard.

Minimum Viable Product

An initial product release becomes a minimum viable product (MVP) when there is hard evidence of customer adoption and use. You have a small group of paying customers who value the core features of the product enough to keep paying. They all have long lists of improvement requests, but the core feature is viable enough to retain them. For Facebook, it was when Zuckerberg expanded the site beyond Harvard to Oxford and then Stanford.

Final Thoughts on Product Discovery

How much should be invested in the product discovery system? The answer is, “it depends”. In the beginning of a startup, your investment in product discovery approaches one hundred percent of available capital. Once you have found product /market fit and your MVP moves into the product management system for further fixes, fills and finishing work, your investment in the product discovery system approaches zero. Not because continuing discoveries of value are no longer important (of course they are). But the type of discovery work you now need is the type that occurs in the product management system. As you take on product gaps and develop proposed fixes, fills and finishing work, the discovery step is about confirming that your proposed solution does indeed improve the customer experience. The product discovery system returns to center stage at the value inflection point called Minimum Viable Expansion (MVE). See below:

This is the point at which you add your next product, or expand to the next vertical. A true product expansion requires that you reactivate the product discovery system with its deep customer immersion, exploration of customer jobs to be done, the high variation of hypotheses and the slow, unpredictable walk down a narrowing path.

As you scale past Minimum Viable Expansion the product discovery system should operate continuously. It’s the only way to continuously reinvent yourself. At enterprise scale it would not be excessive to devote 5% of enterprise value to investment in product discovery (to fund innovation initiatives) and corporate development (to fund venture investments and acquisitions). If the enterprise’s core business is under significant duress, even more may be required.

For the fit systems enterprise, there are many ways to invest in product discovery. Here are a few:

  • Google allows employees to spend 20% of their time working on side projects; side projects sparked the development of AdSense, Gmail, Google Now, and numerous autonomous vehicle projects
  • Many enterprises initiate skunkworks projects inside the company; innovation teams are charged with product discovery and development operating within general boundaries
  • Some enterprises challenge business units to devote a percentage of expense budgets to new product development
  • Some enterprises have created “innovation experimentation teams” charged with new concept development, often co-located in accelerators or incubators like Plug & Play or GSV Labs — these teams have three months to develop a fundable concept (if funded, the entity is launched as a separate company with an enterprise company investment)

One final thought. Unlike the other operating systems of the enterprise, the product discovery efforts defy prediction. Teams may exist in a state of ambiguity and seeming lack of progress for sustained periods of time before finding signal and bursting forth towards MVP. As CEO, it’s on you to accept the product discovery system’s constraints and conform your expectations accordingly. Creating time-based goals and incentives for product discovery makes little sense. It’s better for you to focus on purpose, support the system through your own market and customer engagement, and ensure sufficient resources have been dedicated to the discovery of market truth.

The Product Management System

The product management system exists to build out and improve the product for existing customers and prospects who look like them. Healthy product management systems create products customers love. This system operates on the principle of “narrow outside in”. Thesis variation is more narrow in product management than it is in product discovery. A segmentation scheme has been developed already, the ideal customer profile is clear and real data is flowing from an existing product. It’s different.

Product management is the system in charge of existing product enhancements, customer escalations and fixes, incremental optimizations, and upgrades for improved scalability, resilience, responsiveness, security and maintenance. The product management system advances both the generative imperative (through value optimization) and the adaptive imperative (by making the product more resilient, scalable, and efficient).

Notice how the product management system picks up where the product discovery system leaves off:

A healthy product management system starts with clarity of direction, segregation of duties and an effective balance of alignment and autonomy. Here are some critical success factors:

  • Have a clear product vision
  • Embrace agile principles
  • Determine the domains of your product
  • Define the bounded purpose for each domain
  • Establish OKRs that drive intended business outcomes for each domain
  • Assign a team to each domain
  • Get team composition right — product manager, designer, lead engineer, data analyst, user researcher, other engineers
  • Challenge teams to deliver on business purpose through product ownership — they should own development, operational maintenance and scaling
  • Ensure teams are effectively supported by the engineering and DataOps systems

Jay Melone, in a blog on Medium.com titled “Agile Sprints vs. Design Sprints¹”, summarized well the workflow of product management. Melone teases out three factors — stage, criteria and timing. Timing will vary, of course. He emphasized that while it looks like a linear flow, it’s not. It’s highly iterative:

Inside each domain team, the system works as follows:

The product management system encircles the entire end-to-end product. In a large enterprise that means multiple domains and domain teams, which might look something like this:

Product management domain teams are data driven. They track feature usage and conversion data using time graphs to confirm progress against business outcome objectives, like this:

The choice of domain (how you split up product work) is an important architectural decision. Let’s go back to Spotify. Remember how the company split up its teams:

For Spotify, container squads focus on client platforms — iOS, Android, etc. The feature squads focus on features — such as product launch workflow, or search, or a segment of the user experience workflow. Teams need the technical architecture to be in alignment with the organizational architecture. Spotify leverages a microservices architecture to segregate small, loosely coupled services into domains, each of which is owned by a team.

Once again, the speed of the hypothesize / test / iterate flywheel is a critical success factor. But with the product management system you have an installed base of existing users. This enables your flywheel to be guided by data. Invest in the speed of the flywheel. If a team in the product management system is not completing twenty A/B experiments a week on average, it is not performing up to potential.

Since Chapter 7 explored self-organized teams in some depth, we won’t go deep again. But suffice it to say that teams are outcome focused, not outputfocused. If you are outcome focused, you focus on the impact of software on business outcomes. If you are output focused you build bloatware. You keep adding to an expanding mass of software that is rarely used but must be maintained. It sucks resources without adding value. Don’t build bloatware.

Each team’s mission is to build, design, commit, deploy and maintain software that advances an explicit, unique business purpose. OKRs can be used to define business outcome milestones (for instance, “Reduce time to launch from 30 days to three hours”).

By the way, infrastructure squads are not a part of the product management system. They are better placed inside the engineering system. Infrastructure teams exist to deliver technical leverage to product teams, as well as other software development teams working in support of other systems (for instance, the accounting system).

The Problem with Screwing it Up

What happens when your product management system is broken? Problems snowball. Alan Ngai, VP Architecture at Lightbend describes how system problems can be misdiagnosed and create negatively reinforcing feedback loops that worsen the situation:

  • If top executives don’t think through how to break the product down into domains that can be run by separate teams, the product is built as a monolith, riddled with complicated dependencies
  • As a result, few engineers understand the complexity, turning system upgrades into big, complicated projects
  • If top executives dictate product solutions that must be built, insufficient work is done by teams to confirm the customer value hypotheses, causing solutions to be built for problems customers don’t care about
  • Even if the right features are prioritized, if workflow-specific customer pain points are not adequately researched, customers experience usability issues
  • If infrastructure (both front end and back end) is not adequately monitored, if customer performance isn’t monitored and if there is a lack of safe testing environments, the product isn’t reliable
  • If the product wasn’t built in a way that facilitates rapid onboarding, customers get stuck, slowing launch and slowing time to value
  • Customer frustration with reliability, usability and speed to value increases churn
  • Top management concludes churn is due to an underlying feature gap
  • Instead of fixing issues with reliability and usability, top management requires product and engineering to add features
  • Churn increases, causing management to increase pressure on engineers to launch features faster, which causes engineers to find shortcuts, which increases technical debt
  • Because insufficient time has been spent refactoring code to clean up debt, debt grows — making features ever more complex to build and launch
  • As cascading issues increase customer dissatisfaction, management taps the most senior engineers to triage customer issues so that large customers can be saved
  • This impairs engineering’s development capacity
  • Because the system has become so complex, every project becomes complicated
  • The capacity of a team to scope a project declines
  • As firefighting incidences increase in frequency and project complexity rises, engineering capacity evaporates
  • This results in unplanned delays, causing management to amp up pressure on engineers
  • Failed commitments, platform complexity, daunting technical debt, daily fire drills and unrelenting management pressure cause engineer motivation to plummet
  • The best engineers start leaving the company
  • The stocks of engineer staffing, competency and motivation all decline

Summary

Don’t begin working on feature additions and other product management tasks until you are sure you’ve nailed product discovery. Test hypotheses fast, and don’t feel badly when a test fails. Failure is a valuable lesson in what not to do. Make sure you have gathered enough data to be confident in its predictive power. Only once you know you have signal can you move decisively from product discovery into product management.

Do your teams generate outputs that match an output goal? Or do they yield outcomes that match a business outcome goal? The product discovery and product management systems are all about outcomes. For the fit systems enterprise, it’s always outcomes that matter.


If you liked this article and want to read others, click here.

If you would like more CEO insights into scaling your revenue engine and building a high-growth tech company, please visit us at CEOQuest.com, and follow us on LinkedIn, Twitter, and YouTube.


Notes

  1. Melone, Jay. “Agile Sprints vs. Design Sprints: How and When to Connect These Powerful Frameworks to Create New Products or Rethink Existing Ones”. Medium.com, August 2, 2017. https://medium.com/pminsider/design-sprints-vs-agile-dev-sprints-eb5a11a997a8
Tom Mohr

Leave a Reply

Your email address will not be published. Required fields are marked *