At start-up, the product managers are often founders or the CEO. In this early stage, company leaders have minimal required administrative duties and can adapt quickly. While few start-ups succeed, those that do have an effective product discovery process. Eventually, growth-stage and enterprise companies may lean on the value and brand they created in the past instead of instituting further product innovation.
“My focus is on the unique issues and challenges associated with building technology-powered products, services and experiences.”
Most companies follow a “waterfall process” with engineers who use Agile when they can. This outdated product development mode raises serious issues such as business cases that ask engineers to calculate impossible-to-estimate costs; road maps that prioritize features and projects; product managers who are essentially project managers; ideas from sales and other stakeholders that must be considered and “lipstick on the pig” product design that comes in too late to be useful. Other problems occur when product teams introduce Agile too late into the product cycle and use engineers – the drivers of innovation – only to code. These issues lead to higher opportunity costs in lost time and money as the waterfall process continues to flow. Effective product teams apply the best of Lean and Agile by following these principles:
- Deal with risks – in value, usability, feasibility and business viability – first, before building anything.
- Designers, product managers and engineers should collaborate in all phases of product development.
- The product team should focus on solving the problem – that is, providing business results – rather than on implementing solutions.
The people on your team and their job descriptions and responsibilities are crucial in defining elements of success or failure. Don’t keep your product team in a silo; let it be cross-functional. A strong project team culture builds the team’s efficacy. A strong product team feels like a start-up unit – passionate, flexible and fast – within the larger organization. The team uses a flat organizational structure, and members report to their functional managers. Usually this team includes a product manager, a designer, and two to 12 engineers. Depending on the product, the team may also include a product marketing manager, test automation engineer, user researcher, data analyst and, in larger companies, a delivery manager.
“The product manager has some very specific and very challenging responsibilities…and anyone who tries to tell you otherwise is not doing you any favors.”
The team should be collaborative. The three disciplines of product, design and engineering must work together nonhierarchically to find solutions. Team members should be co-located employees, not contractors. A co-located team will “substantially outperform a dispersed team.” One team should be responsible for all the features, fixes, performance, optimization and content of its product – or of a significant part of it. The company should keep the group together and stable so it can amass sufficient expertise to innovate. This is usually easier in a smaller company, but growth-stage and enterprise companies can scale up as needed. To maintain a product team’s missionary zeal, grant it the autonomy to solve problems while making sure that the members understand the business context and objectives. This 360-degree view gives the team ownership of its outcomes.
“It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.”
Older models for product teams focused on moving through a defined process up to delivery. The new, more effective model focuses on having the team keep working until the product meets company and customer expectations. Teams should reflect the firm’s investment strategy, have minimum dependencies, be empowered, be large or small enough for the job, have a relevant vision and strategy, and align with the business and the user. Review the team’s structure annually to make sure it continues to serve the firm’s needs.
Product managers make sure all aspects of the development process work together. This manager should be a company star with the necessary technical, business and customer knowledge, a zeal for the products, good relationships with top executives and the respect of the product team. If this leader lacks any of these elements, the product will probably fail. While a successful product is a result of the team’s work, an unsuccessful product outcome resides with the product manager.
“It’s easy to get hung up on the minutiae…but what’s really important here is creating the right product culture for success.”
Growing companies need strong executives in product management, product design and technology. These leaders must work together, take a holistic view of the product; review the team’s work; remove obstacles from its path; solve conflicts; and ensure continuity for the user experience and architecture. The product leader needs a solid business and tech background. He or she must excel at team development; support a strong product culture; have a solid sense of the product vision and strategy; complement the CEO’s perspective; and get along well with the CEO and Chief Technology Officer (CTO).
“For most types of businesses, I encourage teams to construct product strategy around a series of product/market fits.”
The CTO should not report to the Chief Information Officer (CIO). That arrangement is a warning flag of a faulty process and has been the cause of many failed products. The CTO’s main responsibility is building and retaining a strong management team that develops staff skills and leadership abilities. The CTO must produce quality products quickly; make sure the architecture can deliver as required; keep senior engineers active throughout product discovery; and zealously support the engineering side of the company.
A holistic definition of a product would cover its functionality, technology, user experience design, offline elements, and methods for gaining users or customers and for generating money from the product. Management might want road maps to make sure that the firm’s teams work on the highest-value elements and to carry out the planning that enables coordination across the company. Beware that most road maps result in wasted effort and failed products.
“Even with ideas that do prove to have potential, it typically takes several iterations to get…this idea to the point where it delivers the necessary business value.”
The company needs to build a strong, modern product team and give them sufficient information on the product vision and strategy – as well as business objectives – so they can find the best solutions for their assigned problems. Teams can communicate their product vision on a storyboard, in a white paper or through a prototype. These “visiontypes” relay the vision and inspire the team, stakeholders and, often, potential customers. They move the vision to reality. Product strategy is a series of planned deliveries to make the product vision concrete. The strategy must allow the product team to coordinate with sales and marketing units.
Cross-functional teams can handle product discovery and delivery, and carry out both steps in tandem. In terms of defining a process, no single path is “correct”. Discovery is a quick way to separate good from bad ideas while producing a validated product. It answers such questions as whether engineers can build the product; whether users will buy it; whether stakeholders support it; and whether customers understand how to use it. Discovery works through all the risks of creating a product before the team writes “even one line of production software.” Discovery techniques include:
- Framing – to identify issues that should be dealt with during product discovery and to understand how that effort fits into the firm’s other work.
- Planning throughout the discovery process – to target large issues and decide how to deal with them.
- “Ideation” – to help generate useful solutions to the project’s issues.
- Prototyping to help evaluate risks.
- Testing – to determine the product’s feasibility, usability, value, business viability, demand, and quantitative and qualitative values.
- Transformation – to move the company away from working under its current methods and toward a more productive strategy.
Prototype as King
In product discovery, teams use prototypes to run numerous – about 10 to 20 weekly – fast experiments cheaply. Choose among many kinds of prototypes, depending on what you need to test. They all require “at least an order of magnitude” less time and expense than building the product. Team engineers should write minimal but sufficient code for feasibility prototypes, which can test new algorithms or technology. Teams can use these tests, which should take only a day or two, to determine if an idea is worth pursuing.
“A product team…bring[s] together different specialized skills and responsibilities and feel[s] real ownership for a product.”
A user prototype can run the gamut from one-dimensional, “low-fidelity” to “high-fidelity” user prototypes, which are simulations, but appear on the surface to be real. Live-data prototypes need to work well enough to collect data, but only for specific case uses, and should include 5% to 10% of the eventual delivery. Usually, these prototypes are necessary to address the significant risks that are present in discovery. Your engineers must create them, not your designers. And even if the test version goes well, never deliver it as your final product. Hybrid prototypes include elements of feasibility, user compatibility and live-data testing. Consider the Wizard of Oz-kind of prototype, which looks like a real system to the user, although an unseen person performs tasks manually that eventually will convert to automation. This prototype is never scalable.
“If we want teams to feel empowered and have missionary-like passion for solving customer problems, we need to give them a significant degree of autonomy.”
Discovery should uncover issues. You must learn whether customers want your product. Demand testing, along with qualitative and quantitative value testing, can help determine if customers demonstrate a demand for a feature or element and, if not, why not. Conduct tests with actual users and customers.
“Even with the best of intentions, product road maps typically lead to very poor business results.”
Talking about transforming the way companies create products is easy; making the necessary changes is much harder. One current technique is to carry out a “discovery sprint” in either planning or prototyping. This method calls for conducting an encapsulated week of discovery, with the goal of solving a large problem or addressing a major risk that confronts the product team.
“It’s a constant struggle between those executives…who are trying to run the business and the product team that is understandably reluctant to commit to dates and deliverables.”
Google Ventures (GV) created a team to help start-ups it invested in by working side-by-side with them for a week. The goal was to work through dozens of product ideas and to solve major business issues. These joint sessions resulted in new ideas and a fresh awareness that significantly affected the product or company. To this end, the GV team wrote Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, which offers sound guidance and a detailed structure teams can use to make the week a success.
“Getting product teams and companies to apply the new techniques and work differently is often easier said than done.”
Perhaps the most difficult task that growing companies face is balancing standardization with innovation. Moving from the flexible, fast pace of a creative start-up to a growth-stage or enterprise company with an established brand or product is challenging. Leaders must make sure that the company creates and fosters a strong product culture to allow product teams to flourish.
“The first truth is that at least half of our ideas are just not going to work.”