Money/time tight, startups must be optimized to learn and move quickly, very little bureaucracy to slow them down. Few that succeed usually really good at product discovery.
Growth‐Stage Companies: Scaling to Success
In addition to hiring lots more people, need to figure out how to replicate earlier successes with new, adjacent products and services while growing core business as fast as possible.
At least half ideas on roadmap are not going to deliver what you hope (really good teams assume at least three quarters of ideas won't perform like they hope)
Biggest flaw of waterfall: all risk is at the end, which means customer validation happens way too late. Key to Lean methods reducing waste, one of biggest forms of waste is to design, build, test, deploy feature/product only to find out it is not what was needed. Many teams believe they're applying Lean principles; yet, they follow the waterfall process: work for months on what they call MVP, don't know what they have and whether it will sell until they've spent substantial time/money—hardly Lean.
Best product teams have already moved past how most teams practice these methods—leveraging core principles of Lean and Agile, but raising bar on what they're trying to achieve and how they work. Three overarching principles:
Risks tackled up front, prior to deciding to build anything, rather than at end. 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 tech we have)
Business viability risk (whether this solution also works for the various aspects of our business—sales, marketing, finance, legal, etc.)
Products defined and designed collaboratively, rather than sequentially. Moved beyond PM defining requirements, designer designing solution, engineering implementing. Instead, product, design, and engineering work side by side, in a give‐and‐take way, to come up with technology‐powered solutions
All about solving problems, not implementing features. Conventional roadmaps are all about output. It's not only about implementing solution. Must ensure solution solves underlying problem. It's about business results.
Two essential high‐level activities product teams: discover product to be built, and deliver that product to market. Done in parallel, PM and designer discover necessary product while engineers deliver.
Discovery: intense collaboration of PM, user experience design, and engineering. Tackling various risks before we write one line of code. Purpose is to quickly separate good ideas from bad. Output is validated backlog. Specifically, get answers to four risks listed above.
Discovery involves running series of quick experiments, done quickly/inexpensively, use prototypes rather than products, require order of magnitude less time and effort.
Product vision: longer‐term objective of this product, normally 2–10 years out. How we as product org intend to deliver on company's mission. Use prototypes to conduct rapid experiments in discovery, then build/release products to test/achieve product/market fit, which is step on the way to delivering on product vision.
Concept of minimum viable product (MVP) is one of most important concepts in product world.
Able to convince vast majority they could have achieved same MVP learning in fraction of time/effort. Months building MVP, could have had same learning in days or, sometimes, hours.
Should be prototype, not product. Building actual product‐quality deliverable to learn, even if deliverable has minimal functionality, leads to substantial waste of time/money, antithesis of Lean.
Mercenaries build whatever they're told to build. Missionaries are true believers in vision and committed to solving problems for their customers. In dedicated product team, team acts and feels much like startup within larger company, very much intention.
Product teams are there to solve hard problems for business. Given clear objectives, own/are empowered to figure out best way to deliver on those objectives, accountable for the results.
PM needs to be among strongest company talent. Without tech sophistication, business savvy, credibility with key executives, deep customer knowledge, passion for product, or respect of product team, sure recipe for failure.
Responsible for evaluating opportunities and determining what gets built and delivered to customers. Describe what needs to get built on product backlog. Hard to make sure what's on backlog is worth building, engineers/designers want to see evidence.
PM considered so important by CEOs/VCs because every business depends on customers. What they buy—or choose to use—is your product. Product is result of what product team builds, and PM is responsible for what product team will build. When product succeeds, it's because everyone on team did what they needed to do. But when a product fails, it's PM's fault. PM is proving ground for future CEOs, VCs want to invest in company with proven product people as co‐founder.
Four key responsibilities of strong PM:
Deep Knowledge of Customer First. Need to become expert on customer: their issues, pains, desires, how they think—and for business products, how they work, and how they decide to buy.
Deep Knowledge of Data and Analytics. Both quantitative and qualitative skills. Most PMs start day with half hour in analytics tools, understanding last 24 hours. Sales/usage analytics, A/B tests results.
Deep Knowledge of Your Business. How it works, role your product plays in your business. This means knowing various stakeholders and constraints they operate under. Convincing each stakeholder you understand their constraints, are committed to only delivering solutions consistent with those constraints.
Deep Knowledge of Your Market and Industry. Not only competitors but key trends in tech, customer behaviors and expectations, relevant industry analysts, and understanding role of social media for your market and customers. Most markets have more competitors than ever before making sticky products, difficult for prospective customers to move from your competitor to you. Not enough to have feature parity with competitor, need to be substantially better to motivate switch. In some companies, so much industry.domain knowledge that PM supplemented with subject matter experts.
Successful PM must be best versions of
Smart. Not raw IQ, intellectually curious, quickly learning/applying new technologies to solve problems for customers, reach new audiences, enable new business models.
Creative. Think outside normal product box of features to solve business problems.
Persistent, push companies way beyond comfort zone with compelling evidence, constant communication, and building bridges across functions in face of stubborn resistance.
Start by becoming expert in users/customers/product/industry. Share openly what you learn, both good and bad. Become company's go‐to person for understanding anything about customer—quantitative and qualitative. Work to establish strong relationship with key stakeholders/business partners. Convince them of two things: (1) You understand constraints they operate under. (2) You will only bring to them solutions that you believe will work within those constraints. Work hard to build/nurture strong collaborative relationship with product team.
Most similar to role of CEO. PM must deeply understand all aspects of business. PM must ensure business outcome, not just ensure product gets defined. Requires good understanding of interrelated parts/constraints of business—financial, marketing, sales, legal, partnership, service, customer environment, technical capabilities, user's experience—and figure out solution that works for all.
Designer sits side by side with PM, full partner on product discovery. UX is any way customers/end users realize value provided by product. Includes all touch points/interactions customer has with company/product. Multiple interfaces, e‐mail, marketing campaigns, sales process, customer support, etc.
Good Designers think about customer's journey over time as they interact with product/company. Constantly test ideas with real users/customers. Built into weekly cadence, they're constantly validating/refining ideas, collecting new insights they might not have been looking for. User testing broader than usability testing. Designers and product teams utilize opportunity to assess value of ideas. Will customers use or buy the product and, if not, why not? Questions to consider:
How will customers first learn about product?
How will we onboard first‐time user and (perhaps gradually) reveal new functionality?
How might users interact at different times during their day?
What other things are competing for user's attention?
How might things be different for one‐month‐old customer versus one‐year‐old customer?
How will we motivate user to higher level of commitment to product?
How will we create moments of gratification?
How will user share their experience with others?
How will customers receive offline service?
What is perceived responsiveness of product?
In strong teams, design informs functionality at least as much as functionality drives design; hugely important concept. Need to make design first‐class member of team. Five keys to successful relationship:
Do whatever you need to do to have designer sit next to you.
Include designer from inception of every idea.
Include designer in as many customer and user interactions as possible. Learn about users and customers together.
Fight temptation to provide designer with your own design ideas. Give them as much room as possible to solve design challenges themselves.
Encourage designer to iterate early and often. Get nitpicky about details with early iterations. Encourage to not just iterate on particular design approach but to explore alternative solutions to problem.
Involve engineers deeply in customer pain/business problems you're trying to solve.
Product marketing managers represent market to product team—positioning, messaging, winning go‐to‐market plan. Deeply engaged with sales channel and know their capabilities, limitations, and current competitive issues.
To ensure holistic view of how entire system fits together, we have tech org leader (CTO/VP engineering). Often helped by group of engineering managers and directors and/or software architects. Critically essential role for companies with large/complex systems, usually direct report to head of tech.
Don't lose these people! Take care of them, don't give them reason to leave or feel need to become manager to make more money. Second, always develop more of these people, each should have at least one person they're developing.
Single most important responsibility of VP product: develop strong team of PMs/designers. Make recruiting, training, ongoing coaching top priority.
Good product orgs have strong team, solid vision, consistent execution. Great orgs add strong product culture: team understands importance of continuous/rapid testing/learning. Understand need for mistakes in order to learn, but need to make them quickly and mitigate risks. Need for continuous innovation. Know great products are result of true collaboration. Respect/value their designers/engineers. Understand power of motivated product team.
Some Group PMs (GPMs) go on to become director/VP of PM, some principal PM, and some stay GPM because they love blend of hands‐on working with own product team and ability to influence other teams/PMs through coaching.
Leader of engineering org (VP engineering or CTO): Org responsible for architecture, engineering, quality, site operations, site security, release/delivery management. Group responsible for building/running company's products/services.
Hallmark of great CTO is continual strive for tech as strategic enabler for business/products. Removing tech as barrier, as well as broadening art of possible for business/product leaders. Six major responsibilities in priority order:
Organization: build excellent org with strong management team committed to developing skills of employees. Measure effectiveness by looking at development plans for employees, retention rate, and evaluation of managers/overall product/tech org by rest of company.
Leadership: represent tech in strategic direction/leadership of company, working with other company executives to inform direction, M&A activity, and build/buy/partner decisions.
Delivery: ensure org can rapidly, reliably, repeatedly deliver quality product to market. Several measures of delivery, including consistency/frequency of release vehicles, and quality/reliability of delivered/launched software. Main obstacle to rapid delivery often tech debt, responsibility of CTO to ensure that company is keeping this at manageable level.
Architecture: ensure company has architecture capable of delivering functionality, scalability, reliability, security and performance it needs to compete and thrive. CTO needs to be leader in cohesive tech strategy looking at sum, not just parts. CTO is orchestrator of company‐wide tech strategy. Measures for architecture will vary, but in general, ensure infra continuously monitored and advanced to keep pace with growth of business, measure customer-impacting outages due to infra or architectural issues.
Discovery: ensure members of senior engineering staff participating actively/contributing significantly throughout product discovery. If engineers/architects only used to write software, only getting fraction of value.
Evangelism: CTO serves as company spokesperson for engineering org, demonstrating leadership in community with developers, partners, and customers. Measured by establishing university relations/recruitment program, sponsoring/participating in several events/year in developer community.
Delivery managers mission is removing obstacles, also team Scrum Master. Help team get stuff live faster. Falls to PM and eng managers without these roles. Once org hits 5 to 10 product teams, this role becomes important.
Many people crave recipe for structuring product teams, there isn't one. Critical core principles:
Alignment with investment strategy. Many companies have teams as reflections of ongoing investments, have certain teams because they've always had them. Phase out products no longer carrying weight. Need to have investment strategy and team structure should be reflection of that.
Minimize Dependencies. Helps teams move faster, be more autonomous. Dependencies change over time, continuously ask how they can be reduced.
Ownership and Autonomy. Should feel empowered, yet accountable for significant part of product offering.
Maximize Leverage. As orgs grow, often find common needs, increased importance of shared services. Realize, however, creating shared services also creates dependencies and can impinge on autonomy.
Product Vision/Strategy. Vision describes where org is trying to go in two to five years, strategy describes major milestones to get there.
Team Size. Min two engineers, one, and only one, PM, and designer if user-facing. Max 10–12 engineers.
Alignment with Architecture. In practice, primary principle for structuring teams is architecture. While we'd love every team to be full stack, not always option in practice. For larger companies, typical to have common services/platform teams. Staff with strong, highly technical PMs (platform PMs).
Alignment with User or Customer. If, for example, company provides a two‐sided marketplace, real advantages to having some teams focus on buyers vs sellers.
Alignment with Business. In larger companies, often have multiple lines of business with common foundation for products. If tech truly independent, we'd treat them as essentially different companies. Roughly similar to aligning by customer type, but business units often selling to same actual customers.
Structure Is Moving Target. Org's needs should/will change over time. Review every year or so.
Source of Innovation.
Great companies disrupt themselves before others disrupt them. Product leadership.
One of key themes of book is focusing on outcome, not output. Typical product roadmaps focus on output, are root cause of most waste/failed efforts in product orgs. No escaping these inconvenient truths:
At least half of product ideas aren't going to work. Customers aren't excited about it, want/try to use it, but too complicated.
Even with valuable ideas, typically takes several iterations to get execution delivering business value management was hoping for, often referred to as time to money.
Weak teams plod through roadmap month after month, strong teams understand/embrace truths. Quickly tackle risks, iterate to effective solution. This is what product discovery is, most important core competency of product org. Prototype/test ideas with users, customers, engineers, business stakeholders in hours/days—rather than weeks/months—it changes dynamics and results.
Anytime you put list of ideas on document called "roadmap," no matter the disclaimers, people across company interpret it as commitment. You're committed to building/delivering now, even when it doesn't solve underlying problem.
Roadmaps serve two purposes
Management wants to make sure teams are working on highest‐business‐value items
Sometimes need to make date‐based commitments, roadmap allows tracking those commitments.
New roadmap mode: management provides each team specific business objectives. Prioritizes business results rather than product ideas.
Compromise for dates: product team does discovery, then commits to dates/deliverables. These types of commitments are minimized.
Product strategy is sequence of products/releases delivered to realize product vision. Aligns product work with sales/marketing orgs. Sell in markets we've demonstrated product/market fit.
10 principles for effective product vision:
Start with why.
Fall in love with problem, not solution.
Don't be afraid to think big with vision.
Don't be afraid to disrupt yourselves because, if you don't, someone else will.
Needs to inspire.
Determine/embrace relevant/meaningful trends.
Skate to where puck is heading, not to where it was.
Be stubborn on vision but flexible on details.
Realize any product vision is leap of faith.
Evangelize continuously, relentlessly.
Good product strategies have these principles in common:
Focus on one target market or persona at a time.
Aligned with business, sales, and go‐to‐market strategies.
Obsess over customers, not over competitors.
Communicate strategy across org.
OKR Technique
Qualitative objectives; quantitative/measurable KRs. KRs measure of business results, not output or tasks. Focus on org's and each team's objectives, latter designed to roll up and achieve former. Don't let personal or functional team objectives dilute/confuse focus.
Keep number for org/team small (one to three objectives, with one to three KRs each). Critical each team tracks progress against objectives weekly. Objectives don't need to cover every little thing, should cover needs. If teams fail substantially, post‐mortem. Score OKRs consistency across org so teams can depend on one another. Shoot for 0.7 score. Teams responsible for proposing KRs for each objective they're assigned.
Focus OKRs at product team level. Focus attention of individuals on these objectives. If different functional orgs have larger objectives, discuss/prioritize at leadership level along with business objectives, then incorporated into relevant product team's objectives.
Top 10 for PMs to sell dream
Use prototype.
Share pain. Show team customer pain you are addressing.
Share vision.
Share learnings generously. After every user test/customer visit, share good and bad.
Share credit generously. Make sure team views it as their product. When things don't go well, step forward and take responsibility.
Learn to give great demo. Especially important with customers/key execs. Not teaching them to operate product, or do user test. Showing them value. Persuasive tool. Get really, really good at it.
Do your homework. Team/stakeholders more likely to follow if you know what you're talking about. Be undisputed expert on users/customers, market, competitors, relevant trends.
Be genuinely excited.
Learn to show some enthusiasm.
Spend time with your team.
Principles of Product Discovery
Essential to get ideas in front of real customers early/often
Purpose: address these critical risks
Will customer buy this/choose to use it? (Value risk)
Can user figure out how to use it? (Usability risk)
Can we build it? (Feasibility risk)
Does solution work for our business? (Business viability risk)
Not just PM's opinion, collect evidence.
Can't count on customers/executives/stakeholders to tell us what to build. Don't know what's possible or what we want until we see it. Historically, in vast majority of innovations, customers had no idea what they now love was even possible.
Most important thing: establish compelling value.
Expect many ideas won't work out, those that do will require several iterations. Most common reason for failed ideas: value, but sometimes design too complicated or would take too long to build.
Must validate ideas on real users/customers. Do this before spending time/expense to build actual product, not after. Goal in discovery: validate ideas fastest, cheapest way possible. Try many ideas, multiple approaches for most promising. Competent teams can test on order of 10–20 iterations/week.
Realize many iterations never make it beyond PM, designer, tech lead. Discovery iteration should be >= order of magnitude less time/effort than delivery iteration.
Teams sometimes start with performance/scale or usability risks. Both legitimate, but generally easier than value risk—do the customers want this particular problem solved and is our proposed solution good enough to get people to switch from what they have now?
Other risks: Financial—can we afford solution? Business development—does solution work for our partners? Marketing—is solution consistent with brand? Sales—is solution something sales can sell? Legal—is it something we can do? Ethical—is it something we should do?
Opportunity assessment save you time/grief: answer four key questions:
What business objective are we addressing? (Objective)
How do we know if we succeeded? (KRs)
What problem will solve for customers? (Customer problem)
What type of customer are we focused on? (Target market)
If you discover solution customers love, then tackle monetization/scale risk. Without that solution, rest of work is wasted. Don't spend time on pricing optimization, sales tools, marketing programs, cutting costs, until/unless you discover truly valuable product.
Story Map Technique: 2D maps, major user activities arrayed along top horizontal, loosely ordered by time. Along vertical, progressive level of detail. As we flesh out each into sets of user tasks, add stories for each. Critical tasks are higher vertically. Holistic view at a glance, helps draw line for different releases and their associated objectives.
Nearly magical power of happy reference customer.
Real customer (not friends/family), who is running product in production (not a trial/prototype), who has paid real money (wasn't given away to entice them), and, most important, who is willing to tell others how much they love it (voluntarily and sincerely).
Customer discovery program technique designed to produce these reference customers. Discovering/developing set of reference customers in parallel with discovering/developing product. Technique takes substantial effort, but is single best leading indicator of future product success.
This is for larger efforts. Good examples: creating new product/business, taking existing product to new market/geography or product redesign.
Basic driver: most common objection is prospective customers want to see other companies, like themselves, already successfully using product. Too few and prospective customer worry product is special, only works for those one or two customers.
For products/services aimed at businesses, key number is six reference customers in a single target market. Otherwise don't get focus you want/need.
Focus on developing set of reference customers for specific target market, which then makes it easy for sales to go after those types of customers. Then expand product to meet needs of next target market.
Look for prospective customers that truly feel pain, near desperate for solution we have, no more than eight. If more, consider beta for larger group. If less, likely not product worth building.
Need them to have people/time willing to work closely with us. Test out early prototypes.
Benefit to them: real input, not lip service, to solution—and, most important, solution that truly works for them.
Sean Ellis test: survey users in target market that have used product recently, know from analytics they've made it to core value of product. Ask how they'd feel if they could no longer use it, "very disappointed," "somewhat disappointed," "don't care," and "no longer relevant because I no longer use.". Want 40% "very disappointed" for product/market fit, but lots of caveats depending on type of product, sample size. For business products, though, customer discovery program with six reference customers in specific target market can declare product/market fit. Something truly worth celebrating.
Customer interviews: Establish regular cadence, bare minimum three hours/week. Trying to understand/learn quickly. Ideally at customer offices. Clearly state beforehand problem you think they have, think about how you'll either confirm or contradict that. Bring PM, designer, and one engineer. Designer drives, PM takes notes, developer observes. Ask open‐ended questions, learn what they're doing today. Debrief with colleagues.
Hack days: directed and undirected. Undirected: explore whatever product ideas you want. Directed: customer problem (e.g., something difficult to learn/use or takes too long to do) or business objective (e.g., "Reduce customer churn rate"/"Increase customer lifetime value").
Prototype key principles
Overarching purpose: learn something at least order of magnitude less time/effort than building product. Think through problem at substantially deeper level than writing/talking. Mitigate risk, discover major issues, collaborate with team using prototype to develop shared understanding.
Create right level of fidelity for intended purpose.
Big limitation of user prototype: not good for proving whether product will sell. People say all kinds of things and then go do something different.
Usability tests
When starting usability test, tell subject this is prototype, not real. Won't hurt feelings giving candid feedback, testing ideas in prototype, not subject. They can't pass/fail—only prototype can.
Keep subjects in use mode, not critique mode. What matters is whether they can easily do tasks they need to do. Doesn't matter if they think something is ugly or should be moved. "What three things on the page would you change?" is no good. Unless subject is designer, answer isn't worthwhile.
Keep quiet and don't help out during testing. However, if they're scrolling page clearly looking for something, okay to ask what as information is valuable to you.
Look for three important cases:
Got through task with no problem, no help
Struggled and moaned, but eventually got through
Got frustrated and gave up
Act like parrot. Helps avoid leading. Tell them what they're doing: "I see you're looking at list on right." Prompts them to tell you what they're trying to do. Repeat questions back to them, usually, they'll want to answer.
Testing value
Can't assume there's demand. Fake door demand test: put button/menu item into UI where it should be. When user clicks, takes them to page explaining you're studying possibility of adding this feature, seeking customers to talk to about it.
Also applies to entire products with landing pages.
Weaning Org Off Roadmaps
Every time you reference roadmap item or discuss it in presentation/meeting, include reminder of business outcome it's intended to help with metrics tracking where you stand in relation to metric.
Goal org moves focus from features launching on specific dates to business results
