Reading Time: 54 minutes

Become the leader your Product Teams need you to be. Product Leadership lessons from the world’s top tech companies.

Marty Cagan with Chris Jones, Silicon Valley Product Group

Ramu Kallepalli
November, 2021

The Setting

Marty’s recent book EMPOWERED is a must read for every product leader, CPO, CEO and anyone interested in creating a strong product organization.   Marty describes empowered product teams, recruiting & coaching members, creating an inspired product vision & product strategy, assigning teams problems to solve and transforming product organization into empowered product teams. 

“Leadership is about recognizing that there’s greatness in everyone, and your job is to create an environment where that greatness can emerge.”

~ Bill Campbell

Learn from Top Tech Companies 

For strong product companies technology is the business.  These companies have strong product leadership and have empowered product teams (product managers, product designers, data scientists and engineers).  The purpose of the product team is to serve customers by creating products customers love, yet work for the business.  

Product leaders, in these companies, are responsible for staffing and coaching product teams, product strategy and converting strategy into action; they are responsible for managing to results.  Empowered product teams depend on skilled product managers, product designers and engineers, and it is the product leaders who are responsible for recruiting, hiring, and coaching these people.  Further, a focused and compelling product strategy, based on quantitative and qualitative insights, is among the most important contributions of product leadership.

In strong product companies, teams are given problems to solve.  They are empowered to solve these problems in the best way they see fit.  In empowered product teams, the product manager ensures that the solutions are valuable (our customers will buy the product and/or choose to use it) and viable (meets needs of the business).  Product designer is responsible to ensure the solutions are usable.   The tech lead is responsible to ensure solutions are feasible.  Together, the product teams own the problem and are responsible and accountable for the results.  Product discovery is about discovering a solution that our customers love, yet works for our business.  Our task is to discover a solution that is valuable, viable, usable and feasible. If product teams are to be empowered to make good decisions, they need to have the strategic context necessary to make those decisions. 

Product vision describes the future (between 3 and 10 years out) we are trying to create and, most importantly, how it improves the lives of our customers.  All empowered product teams need to head in the same direction and contribute in their own way to solving the larger problem.  Product vision is what keeps us inspired and excited to come to work every day.  Product vision is typically the single most powerful recruiting tool for strong product people.  Product principles add to the product vision by speaking to the nature of products that your organization believes it needs to produce. Team topology refers to how we break up the work among different product teams to best enable them to do great work.

Product strategy describes how we plan to accomplish the product vision, while meeting the needs of the business as we go.  The strategy derives from focus, then leverages insights, converts these insights into action, and finally manages the work through to completion.

Critical role of a product leader is to evangelize the product.  Keep communicating the product vision, principles, and product strategy – both to the internal product organization, across the company, in recruiting, onboarding, weekly 1:1 coaching, all-hands meetings, team lunches and everywhere in between.  If you want to have truly empowered product teams, then your success depends very directly on first-level product leaders (people managers).  It is important that these product leaders understand — and can effectively communicate — the product vision, principles, and product strategy from the senior leaders.  These product leaders have three critically important responsibilities:  Staffing, Coaching and Team Objectives.  At a very minimum, coaching involves a weekly 1:1 with the people who report to you as their people manager.  Product leaders have to ensure that each product team has one or two clear objectives they have been assigned quarterly.  These objectives derive directly from the product strategy — it’s where insights are turned into actions.  It takes strong leaders to be self-confident and secure to truly empower the people that work for them, and to stand back and let the team take credit for their successes.  For any company to embark on a journey to become a great product company, the key ingredient is trust.

“Coaching is no longer a specialty: you cannot be a good manager without being a good coach.”

~ Bill Campbell

Coaching 

Your company depends on successful products.  Successful products come from strong product teams.  Coaching is what turns ordinary people into extraordinary product teams.  Developing people is your job #1.  You should be spending most of your time and energy on coaching your teams, creating coaching plans, and actively helping them improve and develop.  You should measure your job performance on successes of your team members, even more than the success of your products.

The assessment is the foundation of coaching the person to success.  This assessment is structured in the form of a gap analysis.  The structure to use is product, process, and people.  Without competence in product knowledge, the rest doesn’t really matter.  Questions to ask on product:  Is the product manager an acknowledged expert on her target users/customers?  Is the product manager skilled with various data tools and considered by her product team and her stakeholders as an acknowledged expert in how the product is actually used by users?  Is the product manager knowledgeable about the industry and domain?  Does she understand the competitive landscape and the relevant industry trends? Does the product manager understand marketing, sales, finance (revenue and costs), services, legal, compliance, privacy, and so on?  Do the stakeholders believe that the product manager understands their concerns and constraints?  Is the product manager considered an acknowledged expert on how her product actually works?  Would she be able to effectively demo to a prospective customer, train a new customer on how to successfully use it, and handle live customer support enquiries?  Product knowledge is table stakes.  A new product manager typically requires two or three months to ramp up to speed on product knowledge, assuming she dives in aggressively and spends several hours per day learning.

Does the product manager have a strong understanding of the product risks and how to address them?   Does she understand how to tackle risks up front, before engineers are asked to build?  Does she focus on the outcome? Once a product is live and in production, does the product manager know how to utilize optimization techniques to rapidly improve and refine her product?  Does she understand her responsibilities to the engineers and to product marketing?  Does she understand the product-development process including discovery and delivery, as well as the product manager’s administrative responsibilities as the team’s product owner?

How effectively does the product manager work with her engineers and product designer?  Is it a  collaborative relationship?  Is there mutual respect?  Is the product manager involving engineers and designer early enough and providing them direct access to customers?  Is the product manager fully leveraging her team’s skills and minds?  How good is the product manager at collaborating with her stakeholders across the company?  Do they feel like they have a true partner in product that is genuinely committed to their business success? Has she established mutual respect and mutual trust with each stakeholder, including the senior leadership of the company?  Is the product manager able to effectively share the product’s vision and product strategy, and motivate and inspire her product team as well as the various stakeholders and others in the company who must contribute to the product?

I typically rate these on a 1-10 scale, with 10 being a skill that is absolutely essential to the job.  Be sure to sit down with each of your product people no less than once a week (1:1 for not less than half hour each time) to discuss progress on the coaching plan.  The core of this technique is a gap analysis.  Two ratings:  The first rating is an assessment of where the employee needs to be in this skill (expectations rating), and the second rating is an assessment of where the employee currently is (capability rating).   Look for areas with the biggest gaps.  I like to limit the initial focus to the top three areas.  Be sure to sit down with each of your product people once a week to discuss progress on the coaching plan.

Product knowledge is where a new product manager spends most of her time in the onboarding process.  It requires 2-3 months of time to ramp up.  Product manager that does not have this level of knowledge has no business serving as PM for her team.  There is no substitute to getting out of the office and visiting users and customers.  First take advantage of the knowledge of your colleagues.  Talk to your customer service or customer success.  Learn who their favorite customers are, and their least favorite, and why.  Understand how customers perceive your product.  Founders have had more customer exposure than anyone, and they are another great resource.  Ask the founders which customers they consider the most helpful for you to truly get to know and understand.  You’re after as many perspectives as you can get.  At every customer interaction, you are looking to learn:  Are the customers who you think they are?  Do they have the problems you think they have?  How do they solve that problem today?  What would it take to get them to switch?  Talk to product designer and tech lead, learn as much from them as possible.

Use user analytics, sales analytics and data warehouse analytics to learn about user data, sales cycle of the product and how this data changes over time.  You need to know how to answer questions with that tool.  You need to understand what the data in the tool is trying to tell you.  Your data analysts are not there to delegate work to them.  They are there to educate and empower you to answer questions with data.  Every product has a set of key performance indicators (KPIs) that collectively describe your product’s health, and while data tools will help you understand where you’re at, your business will dictate which KPIs are most important for you to focus on.

Product manager is expected to become competent in the domain.  Ask the PM to evaluate the top 3 players in the space and to write up a narrative comparing and contrasting strengths and weaknesses of each player–highlighting opportunities.

How their own business works requires the greatest amount of work.  This is the essential difference between competent product managers and those who are not.  Ask the new product manager to fill out the business model canvas (e.g., lean canvas).  There’s always a funnel starting with people becoming aware you exist, and proceeding through to the point where they are an active user and customer.  Think of pirate metrics (AARRR, Acquisition, Activation, Retention, Revenue, Referral). The new PM needs to understand the entire funnel from awareness to trials to onboarding.  It’s especially important to understand the capabilities and limitations of the sales channel.  Your product marketing is your go-to resource about go-to-market strategy.  Also make a friend in finance, understand what those KPIs are.  How is life time value calculated?  Is your lifetime value sufficient compared to your cost to acquire new customers?  Understand additional areas of your particular business.  eCommerce companies have merchandising and companies that sell have international business or supply chains. If an important industry analyst were to offer to come visit your company to discuss your product, the product manager would give the brief herself.  

Product Managers should understand 4 different types of product risk (value, usability, feasibility, and viability) and should know how to test those risks qualitatively and quantitatively.  Product Manager should take CSPO (Certified Scrum Product Owner).  This short course will explain her responsibilities as the product owner for the team.

Modern product management is all about true collaboration between product, design, and engineering.  The PM needs to be knowledgeable about the real contribution of product design and engineering.  This collaboration is built on trust and respect.  Is the designer and engineer bringing potential solutions to the table or just pointing out issues with whatever the PM proposed?  Are they spending too much time talking and not enough time prototyping?  How are they resolving differences of opinion?  The key to successful working relationships with stakeholders is establishing mutual trust.  Understand what each of the stakeholder’s constraints are.  Personally convince each stakeholder that she understands what they are concerned with, and that she’ll make every effort to come up with solutions that work for them.  She will preview those solutions with that stakeholder before the team builds anything.  Building this trust takes time, as there are less interactions, and each interaction carries more weight.  My favorite technique for developing a strong and compelling argument is The Written Narrative.  All product managers should become life-long students of leadership and leaders.

The tech lead is the key partner to the product manager and product designer.  The real potential of a tech lead comes from combining their understanding of technology with an appreciation for the issues customers struggle with.  After visiting an interesting customer, stop by and chat with the tech lead about what you saw and learned, and what they might think about that.  Every single minute you invest in coaching a tech lead on either customers or business context will be among the best possible uses of your time.

Great product marketing requires understanding the market first.  It pressure-tests assumptions based on what the market tells you so you can adapt, position, and market into customers’ true reality.  It makes clear why your product matters and should be loved using customers’ language, experience and needs.  The real indicators of successful product marketing are market adoption and momentum.  Stop trying to pitch your product at every meeting and instead start asking every executive you meet what their most pressing priorities are.  Bring your product marketing early in a startup journey.  Product marketing creates the bones around which the body of marketing and sales work takes shape.

The single favorite coaching tool for helping product people become exceptional:  The Written Narrative.  Product people, product managers, have to make arguments all the time.  Write the narrative explaining your argument and recommendation.  This is roughly a six-page document that describes in narrative form the problem you’re trying to solve, why this will be valuable to your customers and for your business, and your strategy for solving the problem.  The reader will be both inspired and convinced.  As Brad Porter, longtime Amazonian has put it “Speed and scale are weapons, and Amazon has already told everyone its secret … if only they have the discipline to implement it.”  The structure is to write the narrative itself in a few pages and follow this with an FAQ.  Anticipate the concerns and objections that might come from key executives and stakeholders, write up clear answers to these objections.  You might use this narrative to kick off decision meetings like Amazon does.

1 COMPANY MISSION | 2 OBJECTIVES | 3 SCORECARD | 4 PRODUCT VISION & PRINCIPLES | 5 TEAM TOPOLOGY | 6 PRODUCT STRATEGY | 7 PRODUCT TEAM OBJECTIVES (Discovery, Delivery)

There are six types of strategic context:

1. Company mission or purpose of the company is intended to be durable — usually lasting for a decade or more, if not the life of the company. 
2. Every product and every company have key performance indicators (KPIs) or company scorecard / company dashboard / health metrics.  Company scorecard focuses on the most important and informative metrics.  This is how the leaders of the company judge the overall health and performance of the company.
3. Company objectives are selected by the senior leadership,  with the participation of the board, as the most important areas of focus.  Growth, geographic expansion, profitability, or customer satisfaction.  Within these areas of improvement there are specific business targets the company hopes to achieve (the key results).  Company objectives must be outcomes (business results).  The key results are KPIs that are on the company scorecard.
4. The product vision (3-10 years out) describes the inspiring future we are trying to create, and why the future will improve the lives of our customers.  Empowered product teams will be figuring out how to make this vision a reality.
5. Product principles complement the product vision by stating the values and beliefs that are intended to inform the many product decisions that will need to be made.  Product principles help to illuminate the values we prioritize when we make these trade offs.  The product teams need to understand these principles and reasons behind each one.
6. Team topology describes what each product team is responsible for. Each product team needs to understand where they sit in the larger picture and how they relate to the other teams.  We have a set of company objectives that we need to achieve this year, we have a product vision that we need multiple years to achieve, we have multiple product teams — with different skills and areas of responsibility.
7. It is the product strategy that will drive each specific product team’s objectives.  Once each product team has their objectives, they can get to work tackling the problems they need to solve.

The strategic context provided by company mission, company scorecard, company objectives, product vision and principles, and product strategy is meant to apply to all product teams of the company.  Each PM needs to understand this strategic context and demonstrate in her statements, actions, and decisions how her team is contributing to the common goals.

We will continue to focus on hiring and retaining versatile and talented employees, and continue to weigh their compensation to stock options rather than cash. We know our success will be largely affected by our ability to attract and retain a motivated employee base, each of whom must think like, and therefore must actually be, an owner.

~ Jeff Bezos, 1997 letter to shareholders

Creating empowered product teams involve giving product teams ownership of a problem to solve, so that they have the ability to solve problems the best way they see fit.  As a product manager to think like an owner, you need to feel real obligation and responsibility to your customers, your product team, your stakeholders, and your company’s investors.  Why? Because the product team takes their lead from the product manager, and the team and the company executives will judge you by your words and by your actions.  Product team is counting on you to provide strategic context  necessary for designers and engineers to come up with the best possible solution.  Because teams do much better work when given the context and a problem to solve, rather than describing to them the requirements of a solution.  Do your homework on customers, data, business and industry, because the designer and engineers need someone on the team with this knowledge. This would be your direct contribution to solving the problems the team has been assigned.  “There will always be excellent reasons not to ship, and it’s your responsibility to figure out a way over, around, or through each obstacle.”  Your performance will be measured by results, because we need to be careful never to confuse output with outcome.  Our customers care about results, not effort or activity, because in a company, there are many people to ensure that the assets are protected–the sales force, the revenue, the customers, the reputation–and getting things done in a company meant understanding and respecting these constraints by coming up with solutions that work for the business. Leaders of the company would be continuously judging you to decide if you have done your homework, if you are thinking and acting like an owner, and if the product team was in good hands, because you are the canary (bird) in the coal mine.  You have to take the responsibility when things don’t go well, yet give credit to the team when things did go well, because that’s what leaders do.  It is your responsibility to motivate and evangelize your team, because we want a team of missionaries.  You will have the responsibility to ensure success but not the authority to direct people, because innovation depends on true collaboration with design and engineering, which is a peer relationship and not a reporting relationship.

It’s not at all an accident that the top tech product companies in the world use equity, either in the form of stock options or grants, to spread ownership. You don’t want people to leave once they have fully vested, so you continue to award additional stock to your strong performers every year.  An evergreen strategy means that your best people will always feel like they would be leaving behind substantial compensation if they exit before they are fully vested.  This is a clear win-win.  It’s very good for the employee and very good for the company (and hence the company’s shareholders).  It is very powerful to be able to say that the employee is a part owner of the company just as I am.

Tackle risks early; solve problems collaboratively; and be accountable to results.  Run a test to resolve conflicts.  Collaboration is not a compromise.  Find a solution that works. That it is valuable, usable, feasible and viable.  The story map captures the journey a customer takes with the product including activities and tasks they undertake.  Sit around a prototype and discuss the proposed solution on the table.  Our job in product, as an empowered, cross-functional product team,  is to solve the problems we are asked to solve, in ways that our customers love, yet that works for our business.  Each member of the team is there because they bring necessary skills.  True collaboration on an empowered product team is magic, when you have people who are a) motivated and b) skilled in their respective discipline–product management, product design and engineering–and they sit around a prototype or watch a user interact with a prototype.  Engineer points out new possibilities, the designer points out different potential experiences, and the product manager weighs in with the sales-or financial-or privacy-related implications, and after exploring a bunch of approaches, they find one that actually works.  It’s valuable, it’s usable, it’s feasible, and it’s viable.  This is at the heart of customer discovery program technique.  Our job is to discover solutions that our customers love, yet work for our business.  Getting good at true collaboration is at the heart of how strong product teams work.  It’s a combination of skills and mindset, and it often takes active coaching by the manager to help new product people develop this capability.

Healthy relationship with stakeholders is based on true collaboration too.  Strong PM understands that each stakeholder is responsible for some key aspect of the business, and they are a key partner in helping to come up with a solution that works.  A constructive, collaborative relationship with stakeholders is predicated on the product manager having done her homework so she can be that effective partner with stakeholders.  Collaborating with stakeholders and executives involves listening carefully to understand constraints, and thinking hard about solutions that would work for our customers and our business.  You have to coach each product person on the role of each stakeholder, and why they are there, what they are concerned about and why, and what they need to succeed at their jobs.  PMs sometimes need coaching to realize that trust is most easily built if you do it before you need it.

I interpret the imposter syndrome signal differently.  It is my mind warning me of the consequences if I don’t do my homework and truly prepare.  The fear of looking clueless is what keeps me up late preparing, studying, thinking, writing, rehearsing, and iterating.  The fear of looking clueless is also what pushes me to try out my presentation beforehand on some people that I highly respect and I know will tell me honestly if I am not solid in my thinking or my delivery.

Company culture on customer-centricity is heavily influenced by the words and actions of the company’s leaders.  First of all, be very specific and protective over the term “customer” as actual paying customers.  Have a minimum of 3, one-hour customer interactions each week, ongoing, and during the weekly 1:1, ask about these customer interactions.  I also encourage the product person to share with me stories of what they experienced during these visits, and then share these stories widely around the company.  I explain that my purpose is to establish the reputation of this product person as someone who has a deep and personal knowledge of the company’s users and customers.  The true test of customer centricity is when a customer is at a standstill (“showstopper”) because of some problem with our product, is the product person ensuring a sense of urgency and leading by example to come up with an effective solution?  Leaders will proactively reach out to the product team and offer to help in any way they can.  The job of the product team is to innovate on behalf of our customers.

Empowered product teams depend on trust — with stakeholders, customers and your own product team.  Trust is based on competence and character.  Integrity depends on dependability, the company’s best interests and accountability.  Her word and her commitment need to be taken very seriously.  It has to be a high-integrity commitment.  This means not making a commitment until her product team had the opportunity to do sufficient product discovery to reasonably consider the risks of value, usability, feasibility, and viability.  That means leaning on the expertise and experience of the designer and engineers.   Moreover, what you ship must solve the problem for the customer and/or business.  None of us win unless the company wins (this is better demonstrated with equity-based compensation).  With empowerment, comes the responsibility for those results.  If a product team succeeds, it’s because everyone on the team did what they needed to do, but if a product team fails, it’s the product manager.  Think of a feasibility prototype before making the engineers build anything.  The product manager’s career will survive these mistakes if she is on the whole dependable in her commitments, always works toward the company’s best interests, and takes responsibility for her mistakes.

Empowered product team is all about pushing decisions down to the product team level.  Decisions that the rest of your product team, your executives, your stakeholders, and your customers can support and understand, even if they disagree.  Good decisions rest on a foundation of integrity — you are perceived as being dependable in your commitments, you are believed to be acting in the best interests of the company, and you’re willing to be accountable to the results.  We want the parties to feel genuinely heard and respected, even if the decision ended up not going their way.  If you want the support of other key people – stakeholders or customers – then you’ll need to elicit their concerns or constraints and also bring them along on the decision.  If the decision is about enabling technology, we defer to our tech lead.  It’s critically important for the product team to know when and how to run a test to resolve disagreements.  It involves creation of a specific type of prototype, and then using this prototype to collect evidence.  For major decisions, use written narrative with the FAQ section where each anticipated objection or concern is spelled out and addressed.  It is important to emphasize to the team that, while disagreement and debate are necessary and good, at the end we may need to agree to disagree.  Product manager needs to share the various views and opinions that were considered, and then explain the reasoning for the decision and detail how she intends to make that decision successful.

Effective meetings

Organizer was prepared, and information was clear and logical, a solid decision was made, and everyone in the room at least understood — even if they didn’t personally agree (disagree and commit).  There are 3 reasons for meetings:  communication, decisions, and problem solving.  All-hands or a session where leaders explain the product strategy is a communication meeting.  For decision meetings, written narrative works well.  A postmortem after an outage, where we consider what we could do differently going forward to avoid this type of problem in the future, is a problem solving meeting. 

Purpose

First being very clear on the purpose of the meeting is an important start for the meeting organizer.  Attendees:  People that are absolutely essential (need to postpone the meeting without them), and people that are optional.  Make these 2 lists. 

Preparation

If it’s communication, do you have clarity on the context?  Do you have the right medium to communicate this content?  necessary images or visuals?  If it’s a decision meeting, do you have the written narrative, and has it been reviewed by someone who understands the space?  If it’s a problem-solving session, how will you explain the situation or context to the attendees?  Have you gathered relevant data?  Are you prepared to answer the various questions that will come up?   You are there in the meeting to ensure you get to the necessary decision or solution.  After the meeting, notify interested parties of the decision or next steps.  Close the loop.  If you call a meeting, a)  make sure it is truly necessary and warrants the time of all the attendees, and b)  prepare for the meeting to make sure it is efficient, effective, and accomplishes its purpose.

Ethical products

5 big risks that every product team needs to consider are:  1. Will the customer buy it, or choose to use it (value risk)? 2. Can the user figure out how to use it (usability risk)?  3. Can we build it (feasibility risk) and 4. Can shareholders support this solution (business viability risk)? And 5. Should we build it (ethical risk)?  Will the product solution be good for the end-customer?  Does it have a negative impact on the environment or the community?, if all of the emails, documents and discussions around the product were published online.   Will the product be something that you will be proud of as part of your personal brand?  Speak up in a thoughtful way, raise your concerns, but not in a holier than thou accusatory way.  Explain in a way that makes it clear that you care about protecting the best interests of the company.

Product leader needs to focus at least weekly on whether each of her product people feel she is doing meaningful work, progressing in her career, and building the necessary relationships with the team and with the execs that enable her to effectively and successfully lead an empowered product team.

Transforming to a strong, confident, inspiring leader needs four skills.  i) Self awareness:  Skills that got her to this level won’t get her to the next level.  ii) Courage:  to make space for teams to learn and make mistakes.  It takes courage to give meaningful and honest feedback.  Trusting your team will lead to better results than just trusting in yourself.  Leave your tactical skills behind and move into the world of strategy.  It takes courage to be vulnerable.  Courageous leadership is going forward despite the discomfort.  iii) Rules of engagement:  They are still ultimately responsible for successful outcomes.  What information does the leader need in order to trust?  iv) Disrupting yourself:  Even if the leader is self-aware, has the personal courage to make the necessary changes, and has agreed to rules of engagement, it’s no secret that long-held habits can be very hard to break.  Especially habits and behaviors that get to the very core of someone’s identity and feelings of self-worth.

Staffing

It starts with recruiting, then interviewing, hiring, onboarding, annual performance reviews, terminations, and promotions.  The best product companies hire competent people of character, and then coach and develop them into members of extraordinary teams.  Staffing is the responsibility of the hiring manager.  According to Jeff Bezos, “The most important decision at Amazon, has been, and remains, hiring the right talent.”.  You are hiring capable people and giving them the space to do remarkable things.  Everything depends on hiring competent people who share your values and are passionate about pursuing your product vision.  Take the interview process seriously, devote significant time to new employee onboarding, spend continuous effort in coaching and developing your people to reach their potential.

Results in product companies come from product teams, and in fact if that 10x employee brings along toxic behaviors, they will likely cause far more damage to your organization than good.  In recruiting strong, cross-functional, empowered product teams, consider competence and character.  Competence is table stakes for any of your hiring onto an empowered product team.  “A’s hire A’s, but B’s hire C’s”.  A manager that is not an accomplished product manager, designer, or engineer herself is ill-equipped to assess a candidate, and it is easy to see how the company can end up hiring someone that is NOT competent at the job.  It is absolutely critical to ensure competence.  Without competence, the person and the team cannot expect to be trusted by management or leadership.  There is no lasting empowerment without competence.

Product managers, product designers, engineers, data analysts and data scientists, user researchers, and the managers of these people are organization’s core competencies.  Outsourcing these things will kill any chance you have of teams of missionaries.  You have literally created teams of mercenaries.  I promise you that you will end up spending much more and getting much less for it.  Smaller group of missionaries will outperform a larger group of mercenaries, if you consider the need for both discovery and delivery.

Interviewing:  Start with “I am going to ask you to rank these four attributes in order of strongest to weakest.”  1. Execution:  how well do you get things done, do the right thing without being asked, and track lots of simultaneous targets?  2.  Creativity, 3.  Strategy, 4.  Growth.  Test self-awareness and her ability to identify and admit areas of growth.  I am skeptical of a candidate who is unwilling or unable to venture into this conversation.  This also helps ensure that you don’t end up hiring a bunch of clones of yourself.

Produce an offer in 24-48 hours.  Beyond that, you may lose a good candidate.  It demonstrates to the candidate that the company has a hard time making decisions, which is not a good look.  Take reference checks seriously.  Don’t delegate this to anyone else.  Ask if the person would hire the candidate again.  Call for a coffee will yield useful feedback.  Promise to personally invest in coaching and developing the candidate to reach her potential.  If the candidate is good, ask the CEO or other key leader to offer to talk.  This sends a valuable message to the candidate and can also help get the relationship off to a good start.  For most candidates, having someone that is committed to being in their corner, and actively working on their behalf to help them grow professionally, is more important than any other factor.  The hiring manager will need to fulfill that pledge.

“At Amazon, a product team has a clear mission, specific goals, and needs to be cross-functional, dedicated, and co-located.  Why?  Creativity comes from people’s interactions; inspiration comes from intensive concentration.  Just like a start-up, the team huddles together in a garage, experimenting, iterating, discussing, debating, trying and retrying, again and again.”.

Jeff Bezos

You have hired a competent person of character who is ready to start contributing as  a member of one of your product teams.  After her first 60 days, has she scored a public win that helps establish her value to the company? For product managers, that’s primarily around gaining deep knowledge of the customers and a deep knowledge of your business.  Everything is built on this foundation.  This includes a series of customer visits, with an extensive debrief on the learnings afterward.  The debrief covers customers and go-to-market — sales and marketing — and how customer service is handled.  The onboarding also involves time with the finance organization learning the critical KPIs.  Have deep exposure to true users and customers at the foundation.  This applies to all members of the product team — including your engineers.   Introduce Associate Product Manager program.  If you have very strong and proven product leaders who believe in developing talent, then enlist them to participate directly in the coaching.  Set a very high bar for acceptance in this program.  Only accept people who are recognized as among your best minds and highest potential.  The type of person that brings value to every conversation.  The type of person that is driven to make things happen and get results.  For everyone in this program, do a thorough assessment to identify the necessary areas of skills development.  Update this assessment throughout the year.  Put an individualized, 2 year coaching plan in place to help these people reach their potential.  They should be meeting 1:1 with a proven leader at least weekly.  The main way we learn how to create great products is by jumping in and discovering and delivering great products.  Put them in the thick of the product team, only if you are providing this person with intense and ongoing coaching.   Selection of Associate Product Manager (APM)s is based on their potential not on their experience.

Get thorough knowledge of Customer, Business, Industry and Product.   Hiring product managers, product designers and tech leads is hard.  Best product people are working on meaningful problems and creating innovative solutions.  Product managers need to be able to contribute with a deep knowledge of the customer, the business, the industry and their product.  The onboarding of a product person will set the parameters for her level of contribution and success in her role.  On day 1, talk about understanding the customer.  Bring them through our company history and put everything into context.  We share our vision, financial models, talk through our customer discovery, and who our customers have been in the past — and who we want them to be in the future.  Rest of the week, talk through validation, building and prioritizing, learning and measuring, and going to market.  After strategic context, bring in a product person from the company who can speak to each topic and tell stories from her own personal experience.  We are hiring smart product people to solve hard problems in ways our customers love, yet work for our business.

Our primary feedback tool is the weekly 1:1, if not daily interactions.  The purpose of 1:1 is for the employee.  As such, there should never be any performance-related surprises in the annual review.  Common case is a manager that is conflict-averse and avoids giving the constructive criticism that is so necessary.  The manager eventually decides the person is not strong enough, discusses this with HR, and then HR forces the manager to document the issues in a performance review.  The employee is then surprised and confused to learn she’s not actually meeting expectations.  This is unfair to the employee and completely avoidable.  The most basic skill for a competent manager is the willingness and ability to provide honest, timely, and constructive feedback to employees.  Do what is necessary for compliance with respect to performance reviews, but make sure your primary feedback mechanism is your weekly 1:1.

The best way to avoid terminations is to develop your skills in effective recruiting, interviewing, hiring, onboarding, and especially ongoing coaching.  There will be situations where an employee is simply not able to perform the job at the necessary level of competence, despite coaching.  If I can’t coach the person to competence in 3 to 6 months and I have been sharing lack of progress with increasing urgency during our weekly 1:1, I will admit to myself that it is not working.  If there are serious behavioral issues that damage trust in the organization and leave people feeling disrespected or worse, I am honest with the person about their behavior and the impact it has on the trust and culture in the team.  Removing the toxic person is the right thing to do, and others in the organization would rise to the occasion and the broader organization will be grateful for the improvement in the workplace atmosphere.

Promotions are the best.  Most visible and tangible sign of success as a manager is when your people are promoted.  If she is willing to put in the effort, I am willing to do my best to help her reach her career goals. As Tom Peters said “Leaders don’t create followers, they create more leaders.”  “People join a company, but they leave their manager.”

Product Vision and Principles

Valuable, Viable, usable and feasible.  Most companies have a mission statement that summarizes the purpose of the business, but a mission statement says nothing about how we plan to deliver on this mission.

A good Product Vision

• Keeps us focused on the customer.
• Serves as the North Star for the product organization so that we have a common understanding of what we are hoping to accomplish together.
• Inspires ordinary people to create extraordinary products.
• Provides us with meaningful work.  How you can positively impact the lives of users and customers is meaningful.
• Leverages industry trends and technologies that we believe can help us solve problems for our customers in ways that are just now possible
• Provides the engineering with enough clarity about what’s coming in the next several years so they can ensure they have in place an architecture that can serve the need.
• Is a primary driver of the team topology.

A strong product vision serves as one of the most powerful recruiting tools for strong product people and for evangelising to senior executives, investors, sales and marketing staff.  When done well, product vision is compelling, inspiring, and empowering – leaving the product teams feeling excited to begin the hard work of making this vision a reality.

When I work on product vision, the very first thing I do is find a strong product designer to collaborate with to create what is known as a visiontype.  The product vision represents the common goal and constantly reminds us of the larger purpose. Be sure that every member of your product teams understands the answers to 2 critical questions:

• What is the endgame?
• How does the work of my team contribute to this larger whole 

The product vision describes the future you are trying to create.  In what ways will you improve the lives of your customers?  You are not trying to explain how you will get there –  that is to come from the product strategy and the product discovery work.  Your roadmap is just a set of features and projects that you believe might help you get there.  The time frame for product vision is between 3 and 10 years out.  Remember that customers don’t care about our technology – they care about how well we solve their problems.  Purpose of technology is to solve problems in ways that customers love.  The head of product is responsible for ensuring the organization has a compelling product vision, as well as the product strategy that can deliver on that product vision.

In order to come up with a compelling product vision, the head of product will need to work very closely with the head of design and the head of engineering.  In startups, the CEO is the effective head of product, so this happens naturally.

Vision’s purpose is to inspire.  The minimum is typically to create a visiontype, and we often produce video of this visiontype.  A visiontype is a conceptual prototype – a high-fidelity user prototype.  The difference between a high-fidelity user prototype used as a visiontype, and a high-fidelity user prototype used in product discovery, is the scope of what’s covered by the prototype.  The visiontype describes the world once the vision is a reality — 3 years or 10 years in the future.  The product discovery prototype describes the new feature or experience for something we will likely build in the coming weeks.  Another effective way to communicate a product vision is with storyboarding, much like what is done to create and share an outline of a movie.  As with a video showing off a visiontype, a storyboard focuses on the emotion and the customer experience and not on the details. If the vision was available today, do people have the problems we think they have?  Are the problems serious enough, and their current options weak enough, that they’re open to new solutions?  Product vision is largely a leap of faith.  We’re betting on ourselves; that we’ll be able to discover a solution that delivers on the promise of the vision.  Product vision is a recruiting tool and an evangelism tool.  Strong product people want to work on something meaningful.  They want to work on something larger than themselves.  They want to be missionaries and not mercenaries.  The vision needs to be compelling, and as a leader responsible for recruiting staff, you need to be persuasive.  It is not just potential employees that you need to persuade.  Your company’s executives, investors, stakeholders, sales and marketing staff, customer service and customer success staff, and key influencers from across the company and beyond — you need all these people to understand the future you are trying to create.  Evangelising is something that is never finished.

Product vision is usually what customers are hungry for.  We should much rather share a product vision than a product roadmap because it is a near certainty that you will want to change your roadmap often.  Sharing product vision validates the vision.  Remember to be stubborn on vision, but flexible on details.  Sharing the vision is fine, but sharing the roadmap is very dangerous.

Product Principles and Ethics

Product principles complement the product vision by stating the values and beliefs that are intended to inform the many product decisions that will need to be made.

Audrey Crane:

Audrey was working at the nexus of product and design when much of the internet was just emerging.  She learnt from one of the pioneers of modern product design, Hugh Dubberly, when Hugh ran design for Netscape.  Audrey recently published a book What CEOs Need to Know about Design.  In theater, there is a team of people working toward a common goal.  They’re selected for their experience, skill, and potential, as well as their ability to work well with other people on the team.  Director’s highest responsibility is to bring to bear the best of what each team member has to offer.  Rarely is the director the most highly skilled at any of the jobs that others on her team do.  Of course, she must be knowledgeable so that she can appreciate, support, and grow each person on the team, but she isn’t the best, and in some ways, that’s the point.  A director will “give notes” (critique) regularly.  “That was great, do more of it,” or “Totally confused by your choice there”– is a given in any relationship with a director.  Mutual respect and collaboration demand clear, direct feedback.  In the theater, celebrations are built in.  Everyone takes a minute to step back and consider what they’ve accomplished together.  I think we don’t take enough opportunities to celebrate in business, and I look for ways large and small that individuals and teams can be honored.  As a leader, there’s nothing better than assembling a talented cast, providing them a story they can get excited about, coaching them to reach their potential, and watching them creating something special together.

Team Topology

The topology helps answer the question of how a company should organize it’s product people into teams to best enable them to do great work.  Your topology choices should be guided by principles that support team empowerment.  These include giving teams real ownership of the space of problems they will be responsible for, providing autonomy in their ability to deliver the solutions to the problems they’re asked to solve, and alignment with various aspects of the company’s customers, business and technology.  Alignment itself is complex and requires reconciling the scope of individual teams with the broader context of business goals, types of customers, organizational reporting structure, technology architecture, and product vision.  Every topology creates its own set of dependencies between product teams, and leaders must consider the trade-offs.  Team topology needs to evolve over time as the needs and circumstances change.  Team topology needs to be a decision made by leaders of product and design, and the leaders of engineering, working together.  The best topology will balance the needs of these key product leaders. Optimizing for empowerment requires balancing three interrelated goals:  ownership, autonomy and alignment.

Ownership sets the scope of each team’s full responsibilities around functionality, experience, quality, performance, and technical debt.  Empowerment improves when each product team has something meaningful that they are responsible for.  A team that sees itself as responsible for a meaningful problem is inspired by their connection to the larger cause.  A larger scope of ownership is better for empowerment.  Empowerment doesn’t just depend on the scope of ownership — it also requires clarity of ownership.  A good topology should resolve more ownership questions than it raises.

Autonomy means that when we give teams problems to solve, they have enough control so that they can solve the problem in the best possible way that they see fit.  A topology that results in too many dependencies can make this difficult.

Alignment:  When alignment is high, teams generally have fewer dependencies to get things done.  They can make faster decisions and are more connected with business level outcomes.  When alignment is high, empowerment is improved.  The two most significant dimensions to consider when getting the alignment at the highest level are the architecture and the business.  The architecture is based on the product vision.  Teams can own a meaningful scope and can be given autonomy to make significant product decisions.  Alignment with the business includes how the product team relates to the organization — e.g., to different business units, different go-to-market strategies, different customer types, or different market segments.  Overarching objective is to optimize for empowerment.  The best way to do this is through ownership, autonomy and alignment.

Team Types

Two types of product teams are:  platform teams, which manage services so they can be easily leveraged by other teams, and experience teams, which are responsible for how the product value is exposed to users and customers.  Product and engineering leadership must determine topology together.   Examples of platform teams include:

• A platform team that is responsible for shared services such as authentication or authorization.
• A platform team that is responsible for maintaining a library of reusable interface components.
• A platform team that is responsible for providing tools to developers for test and release automation.
• A platform team creates an abstraction for integration with a legacy system.
• A platform team that manages payment processing.
• A platform team that manages a highly specialized tax calculation.

In top product organizations, the best engineers in the company are asked to work on platform teams because of the leverage and importance.  In large, top tech companies, half of the product teams are platform teams.  Platforms reduce the cognitive load for experience teams.  Experience teams are able to use platform services without having to understand how they are implemented.  They can focus their energy on the customer or business problem they are working to solve.

If a product team is working on the experience for the company’s customers/consumers, this is called customer-facing experience team.  If a product team is working on a product experience for internal employees (customer service agents or in-store associates), this is called a customer-enabling experience team.  Experience teams are most empowered when they are given as much end-to-end responsibility as possible.  Such teams have a meaningful sense of ownership, more autonomy, and it’s easier for them to see their impact on solving customer problems and achieving business results.

Rich platform is a powerful tool for enabling a broader (end-to-end) scope of ownership for the experience teams.  Platform teams reduce the load required to use the underlying technology, creating cognitive capacity for experience teams to own more aspects of the customer problems.

Empowering Platform Teams

Platform teams create leverage and encapsulate complexity for experience teams.  Platform teams raise the level of empowerment for other teams by abstracting away the underlying complexity of the services and the architecture.  Platform team and experience team should define an API that represents a form of contract between the platform team and the experience team, and then each team is able to work largely independently to complete their work.  E.g., A platform team manages all payment complexity and exposes it to the experience team as an API.  The product team responsible for the checkout experience creates the user-facing flows, while the platform team implements the integration with the backend payment processes.  The two teams come together for testing and delivery.  The platform team needs to have the same strategic context and goal as the experience team.  They are connected as to why the work is important, and what it means for the business.  A growing number of companies are working to manage their internal platforms more like external platform (Platform-as-a-Product).  The team objectives and the level of empowerment of the platform teams are comparable to experience teams.

Empowering Experience Teams

Experience teams are responsible for how the product value is perceived by the actual users or customers.  Experience teams are most empowered when they are given as much end-to-end responsibility as possible.  This happens when the scope of ownership for each team follows other natural patterns of the business such as the sales channel, market segment, or user type.

• By user type or persona (e.g., Riders Team, Drivers Team)
• By a market segment (e.g., Electronics Team, Fashion Team)
• By customer journey (e.g., Onboarding Team, Retention Team)
• By sales channel (e.g., self-service team, direct sales team)
• By business KPI (e.g., New-User Growth Team, Conversion Team)
• By Geography (e.g., North America Team, Asia Pacific Team)

Experience teams have areas of ownership that match the outcomes that the business needs.  There is a direct link between business outcomes and product work, and the teams can be given the autonomy to solve business problems directly.  The product is built on a rich platform of common services (catalog management, billing, account management, etc.).  Experience  teams are then aligned by category.  The goal is to organize the experience teams in a way that allows them to best service their specific customer and also align with other parts of the company.

Most marketplaces are two-sided, it is often empowering for the topology to organize experience teams by the side of the marketplace.  Customer-enabling product teams create tools and systems that are used by the company’s internal employees who are providing some vital part of the customer experience.  A topology can empower experience teams by aligning them with the end-to-end needs of the different types of company internal users.  Experience team includes a dedicated product designer.  This is an acknowledgement of how critically important product design is to strong products.  Design is far too important to be run as an internal service.  It needs to be a first-class member of the product team, just as the product manager and tech lead are.  The design manager can ensure a holistic view of design by establishing design standards, guidelines, and design systems; reviewing the work of the designers; and also by conducting design strategy and review sessions with the broader group of product designers.  Engineering reporting structures are organized around specific skill sets.  Groups of data engineers, front-end engineers, and mobile engineers each typically report to separate managers.  This ensures any engineering manager is able to provide skill-specific coaching to every engineer on her team.  There is no reason that reporting relationships should dictate team topology.

Co-location is a significant advantage for true innovation..  The dynamics of product discovery depend on intense collaboration — especially between product management, product design and engineering.  If your team is building services for consumers or businesses in India, there’s a real advantage to being based in India.

Swarming:  As many team members as possible work simultaneously on the same priority item until it is done.  When a team is in a remote office or working remotely, the product manager needs to make extra effort to develop and maintain the necessary relationships with the executives and stakeholders.  Optimize for the product team as opposed to optimizing for the managers, or for access to customers, of anything else.  With the principle of optimizing for the product team, colocate product managers, designers and engineers together.

If the number of engineers, in a product team, is greater than `15, think of the topology of product teams.  You should optimize for the empowerment of teams by focusing on the dimensions of ownership, autonomy, and alignment.  If you’re consistently making major changes to the team topology more than once a year, it is a sign that something is wrong.

Product Strategy

Empowered product teams are all about giving teams hard problems to solve, and then giving them the space to solve them.  HOW do we decide which problems they should solve?  Product strategy is all about answering that question.  An effective product strategy is absolutely essential to enabling ordinary people to create extraordinary products, because it focuses and leverages their talents.

Not miscalculation, bad strategy is the active avoidance of the hard work of crafting a good strategy.  One common reason for choosing avoidance is the pain or difficulty of choice.  When leaders are unwilling or unable to make choices among competing values and parties, bad strategy is the consequence.

Richard Rumelt, Good Strategy/Bad Strategy (New York:  Crown Business, 2011

Whatever the goal is, your strategy is how you’re planning to go about accomplishing that goal.  Strategy doesn’t cover the details — those are the tactics we’ll use to achieve the goal.  Strategy is the overall approach and the rationale for that approach.

Product Strategy:  How do we make the product vision a reality, while meeting the needs of the company as we go?  In terms of empowered product teams, product strategy helps us decide what problems to solve, product discovery helps us figure out the tactics that can actually solve the problems, and product delivery builds the solution so we can bring it to market.

Product strategy requires 4 things that are not easy for most companies:

1. Be willing to make tough choices on what’s really important.
2. Generating, identifying, and leveraging insights.
3. Converting insights into action.
4. Active management without resorting to micromanagement.

Product strategy starts with focus and then depends on insights.  And insights come from study and thought, analyzing the data and from learning from our customers.  The insights might pertain to the dynamics of our business, our capabilities, new enabling technologies, the competitive landscape, how the market is evolving, or our customers.  Once we have decided what’s critically important (focus) and studied the landscape to identify the levers and opportunities (insights) then we need to convert those insights into action.  As product teams pursue their objectives, some make more progress than others, some need help or encounter major obstacles, some find they need to collaborate with other teams, some realize they’re missing key capabilities, or any of a hundred other possible situations.  Properly managing this activity requires smart, engaged leaders practicing servant leadership.  Product strategy is the more important skill, and certainly more difficult.  Product strategy requires choice, thinking and effort.

Focus

The main thing is to keep the main thing, the main thing.

Jim Barksdale

Pick 2-3 truly important things that can make an impact.  The problem is getting the right things done — the things that matter, the things that will have an impact, the things a company is trying to achieve to ensure success. By not picking your battles and focusing on the few truly critical problems, most of the work going on does not make an impact.  And for the truly critical priorities, there is not enough attention to actually move the needle.  Kanban WIP (work in progress) limits essentially says that we’ll get more work done (throughput) if we limit the number of things our product team is working on at any one time.  While this concept is definitely useful at the level of a product team, it becomes absolutely critical at the level of the broader organization.  The bottom line is that an organization will get more critical work accomplished if it focuses on just a few items at a time.

Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes.

Richard Rumel in Good Strategy/Bad Strategy

Insights

My favorite and most difficult aspect of product strategy, which is to generate, identify, and leverage the insights that will provide the foundation of the product strategy.

Good strategy … does not pop out of some “strategic management” tool, matrix, chart, triangle, or fill-in-the-blank scheme.  You’ve spent hours studying your data, your customers, the enabling technologies, and your industry.  The company objectives, the company scorecard/dashboard, and the product vision — is the foundation for any kind of significant insight.  So studying this is all part of doing your homework as a product leader.  Insights can come from anyone or anywhere.  Find inspiration in an industry analysis, a chat with a salesperson, a new enabling technology, a seemingly random comment from a customer, or an academic paper.  Without preparation, you won’t recognize the insight — even if it’s right in front of you.  You might never know what might help you connect the dots, so always keep an eye out and an open mind.  The big insights that form the foundation of successful product strategies come from an analysis of the product data related to your business model, your acquisition funnel, your customer retention factors, your sales execution data, and hundreds of other important indicators of the state of your company.  It’s normal today for product teams to be running live-data tests on a near constant basis.  You learn something from every test, but every once in a while, you learn something truly important — a potentially valuable insight.  The key is to know enough to spot this learning, and then leverage this learning into meaningful action.

Qualitative insights:  I am a fan of having strong user researchers in the organization.  The insights they generate are qualitative and are not “statistically significant””, but don’t let that bother you — qualitative insights are often profound and can literally change the course of your company.  The user research community breaks down insights into two types.  The fist is evaluative, which means, what did we learn from testing out this new product idea?  Did it work or not, and if not, why not?  The second type of insights are generative.  Did we uncover any new opportunities that we aren’t pursuing, but maybe we should?  In product discovery, our learning is evaluative.  We’re focused on finding a solution that actually works.  Anytime we interact with users and customers, we have a chance to learn more about them, and sometimes we discover even bigger opportunities than the ones we’re testing out, if we’re open to it.  This is a generative insight.  Too many organizations are either not doing this ongoing learning about their customers, or, even if they are, they are not set up to leverage the insights that are generated (usually because their feature teams are already over-subscribed just trying to serve the business).  So, the learnings are all too often ignored.  Spend time with users and customers every week.

If the technology is important to you, your company needs to learn that technology soon.  It is the empowered engineers that often identify these enabling technologies and proactively bring the possibilities to the leaders, usually in the form of a prototype. If you can recruit one of these management consultants to come join your product organization, they can often be coached into exceptionally strong product managers and product leaders.

These four types of insights (Quantitative, Qualitative, Technology and Industry) are always the subject of interest and discussion in strong product organization.  The key is to make sure these learnings — whether they are coming from the data, customer visits, enabling technology, industry analysis, or any other source — make it to the product leaders.  This is an important benefit of weekly 1:1s.  Leaders need to take these learnings and pass them along to other teams that may benefit from these insights, and help to build their understanding of the holistic business.  Head of product should aggregate the key learnings and insights from all the different teams in her areas, and at the weekly or bi-weekly all-hands, she should summarize the most important of these learnings and insights, and share them with the broader organization.

During our work on the product strategy, or during a product team’s product discovery work, we discover an insight that changes everything.  This is called a vision pivot, and these vision pivots have both saved and created countless companies.  Slack, YouTube, Facebook, and Netflix are just a few of the companies that experienced this.  “We need to be stubborn on our product vision” ~ Jeff Bezos.  The vision pivot is most relevant when our insights lead to a larger opportunity, Not when we realize that the problems are harder than we thought.

Actions

We have focused on a very small number of critical problems, and we have done the hard work to identify the key insights that will power our product strategy.  We need to turn these insights into action, but there are two ways to do this.  The difference boils down to whether you give your product teams features to build, or problems to solve. Empowered team generates consistently better results — in terms of innovation and delivering outcomes.  In the empowered team model, provide teams with the set of specific problems they each need to solve, and give them the space to determine the best way to solve those problems.  The most popular technique for managing these problems is the OKR (objectives and key results).  Objectives are the customer or business problem we need solved, and the key results are how we measure the progress.  We need to provide the product teams with their specific objectives, which are known as team objectives.  All that is really required is for a knowledgeable leader to sit down with the relevant product teams, explain the strategic context — including the product strategy — and then tell each team which problems you need them to work on, and what business results they should measure.

Management

We have focused the organization on a small number of truly important problems, we have identified the key insights that we will leverage, and we have converted these insights into actions in the form of objectives for each product team.  During 1:1, you’ll hear issues or obstacles, and you’ll coach on the best way to handle them.  You’ll need to help by talking to a stakeholder, or finding an additional engineer, or talking to another team about their need to help with a problem etc…  You are responding to their requests for help.  It is servant leadership and you’re being asked to help remove an impediment.  Weekly tracking and coaching is so important.  You as the manager are ensuring that the product team is making progress, and also as important learnings or insights are discovered, or major issues are identified, they are shared with you so this knowledge can be aggregated and disseminated to the relevant teams.  Once again, with empowered product teams, you don’t need less management, you need better management.

Team Objectives

The OKR technique came from companies that had empowered product teams in their DNA.  The main idea is to give product teams real problems to solve, and then to give the teams the space to solve them.  This goes right to the core of enabling ordinary people to create extraordinary products.  To get the benefit of OKRs, there are three prerequisites:

1. Move from the feature team model to the empowered product team model.
2. Stop doing manager objectives and individual objectives, and instead focus on team objectives.
3. Leaders need to step up and do their part to turn product strategy into action.

We empower teams through team objectives.  The point of team objectives is to execute on our product strategy, and this is where we convert our strategy into action.  We need to discuss how work is assigned to product teams in ways that are both empowering yet also accountable.

Empowerment

We know what actions we need each product team to pursue, we need to discuss how we assign this work in such a way as to empower the team by a) giving them a problem to solve rather than a feature to build, and b) ensuring they have the necessary strategic context to understand the “why” and make good decisions.  The most important point to understand about team objectives is that, first and foremost, they are intended to give the product team the space to come up with solutions to hard and important problems.  This is in stark contrast to a typical product roadmap, which provides the team with a prioritized list of features and projects to build.

• The best people to determine the most appropriate solution are those closest to the problem, with the necessary skills — the product team.
• We want the team to take responsibility for achieving the desired outcome.
• If the first solution team comes up with does not produce the desired outcome, they know they must continue to iterate and/or try alternative approaches until they find a solution that does.  

What is important is (1) their focus is on a small number of meaningful objectives, and (2) they are measuring the results based on business results, not output or activities.  Examples of good objectives are:

• Reduce the frequency of parcels delivered to the wrong address
• Increase the percentage of shipments, delivered with next-day delivery
• Reduce the percentages of images flagged as inappropriate
• Reduce the subscriber churn rate
• Demonstrate product/market fit for an existing product in a new market
• Decrease the time it takes a job seeker to find a new job
• Reduce the operational costs of fulfillment
• Reduce the cost to acquire a new customer
• Increase the lifetime value of the customer
• Reduce the percentage of customers that require customer service assistance
• Reduce the average time spent handling a customer service call
• Increase the percentage of new customers that successfully create an account
• Reduce the time for a user to produce their first monthly report
• Reduce the time required to deploy a new or updated service to production
• Improve the site availability

Once a product team understands the strategic context and has had a chance to investigate the objective, they find that it may make more sense to rephrase, or change the emphasis, or generalize the objective. This back and forth between the leader and the product team is both normal and healthy.  They are problems to solve and not features to build.  Example objectives are all qualitative.  The quantitative dimension will be discussed in the key results.  Objective is the problem to solve, the key results tell us how we define success.  We must define success by business results (aka outcome).  We want between two and four key results for each objective.  E.g. of key results for the objective “reduce the frequency of parcels delivered to the wrong address.”

Potential key results:

• Reduce the percentage of incorrect deliveries
• While ensuring that total deliveries continue to grow
• While ensuring the cost of delivery does not grow

We don’t yet have the expected values or time frames because those will need to come from the team.  If we were to provide to the team explicit measures of success including time frame, they won’t feel that ownership over the commitment that we want in an empowered team.  So the actual quantitative values need to come from the teams.

The best team objective will come from a back-and-forth dialog between the leader and the team.  As teams investigate and consider, they often find new and better approaches that may suggest different key results, or even a modified objective.  You don’t want a passive team — if the team is not actively engaged and debating, be sure to explicitly ask them what they think and why.  Sometimes a team will be tempted to define their key results by something that is easy to measure rather than what’s meaningful to measure.

We must provide these teams with the context necessary to make good decisions.  We need to share the strategic context — especially the product vision and product strategy — with the product teams for four main reasons:

1. It’s critical that the team have a deep understanding of the ultimate goal and why this is an important problem to solve.
2. We want teams to start thinking through the insights, and considering how they each might be able to contribute to solving the key problems.
3. We want the teams to think through implications of the upcoming work.  Perhaps there are dependencies that are not immediately visible.  Or technologies or skills that we will need to acquire.
4. We love it when teams express a special interest in working on specific problems.  We can’t always accommodate every team working on the problems they request, but we are certainly motivated to try.

Assignment

It is the responsibility of the leaders to decide which problems should be worked on by which product teams.  The whole point of assigning objectives to product teams is to execute on the product strategy.  The product strategy is all about deciding which problems to work on.  Assigning objectives to product teams is both a top-down and bottom-up process, and it often requires iteration.

These assignments are a function of the product strategy and the team topology.  The strategy tells us which problems to solve, and the topology will imply which teams are best positioned to tackle each problem.  In aggregate, the organization is covering as much of the overall organizational objectives as possible. Once a team is asked to pursue an objective, the first thing they need to do is consider what the appropriate key results should be, and what they believe they can accomplish.  Encourage the team to jump in and not get stuck in paralysis by analysis, and acknowledge with them that they will learn much more as they progress, and the confidence will be low in the first quarter because they are still learning what they don’t know.  The team will also need guidance from leadership on how ambitious or conservative they should be in pursuing solutions.

Once the leaders have worked with the product teams to decide which product teams will pursue which problems, they then need to ensure that the product teams and the broader organization are aligned.  Any necessary platform team efforts need to be aligned to do the work necessary to support the experience product teams.  Sales and marketing efforts need to be aligned.  “Keep-the-lights-on” work involves fixing critical problems, responding to customer issues, providing assistance to other teams, technical debt, etc..

If you have a strong product strategy — based on focus and insights — and the product teams are working on important customer and business problems, where the work is hard but would cause meaningful impact, then in many cases the objectives will span multiple quarters.   Re-platforming work – one to three years of work – or major product challenges such as reducing customer churn or establishing product/market fit.  Break up the work into intermediate product results.  Let’s say the goal is to get six referenceable customers on the path to product/market fit.  We might have a goal of getting 2 referenceable customers this quarter or a good key result would be getting eight prospective customers to sign a non-binding letter of intent to buy.

Ambition

Be clear on the level of ambition they should strive for in their discovery work.  Should the team focus on low-risk but low-reward “roof shot,” or should they strive for more substantial and dramatic improvements “moon shot”? Going for a 10x improvement is a moonshot.  It’s high risk, but it’s also potentially high reward.  80% likely to achieve a roof shot versus 20% likely to achieve a moon shot.  Leaders are managing a portfolio of potential risk and reward.  Be sure to clearly communicate the level of risk across the organization.

High-Integrity Commitments

In all businesses there are occasional situations where something important must be delivered by a specific deadline date.  Teams must be able to provide dates and deliverables when necessary.  Dates the leaders can count on.  If you’re used to the model of doing product discovery in parallel with product delivery, coming up with a high-confidence date is not hard, so long as the company is willing to wait until the necessary product discovery work has been done before the date is provided (usually a few days).  If a company has too many of these date-driven commitments, it is usually a sign of more serious issues, but I always try to explain to product teams that some amount, of high-integrity commitments, is necessary when trying to run a business.

Product discovery often involves creating a quick prototype, such as a feasibility prototype, to ensure the engineers understand the scope of the necessary work to produce the necessary deliverable.  Once the product team believes they understand the solution sufficiently, they can estimate with high confidence how long it will take for them to deliver on this commitment (feasibility), and also whether that solution will work for the customer (value and usability) and work for our company (viability).  The actual deliverable that is the commitment needs to be noted and tracked independently of the key results.  The team that makes a high-integrity commitment is absolutely expected to deliver, or at the first sign of trouble, they need to raise the flag early and ask for help.

Shared Team Objectives

Both experience-team and a platform-team have the same objective because the platform team is expected to provide one or more new services to enable the experience product team.  Teams collaborate to establish a simple form of contract with each other in the form of an API, and then both proceed to work on their sides, and then they will again collaborate on testing and delivery.  In certain situations, the teams will co-locate for a few days or a week in what is sometimes called a “swarm,”, which is an intense, highly collaborative technique to dive deep together on either or both discovery and delivery work for a particularly challenging problem.

Management

Much of the product strategy requires ongoing tracking and managing by the product leaders, the team objectives require ongoing tracking and managing by the product team.  Product teams are actively managing progress on the team objectives.  Product teams stay on top of progress by discussing weekly check-ins where they are, what is upcoming, and where they might need help.  These weekly team objective check-ins are the key mechanism that teams use to track and manage their own progress.  Occasionally, the teams will raise an issue that requires the leaders to coordinate to resolve conflicts or issues. In tech-companies, we either all succeed, or none of us succeed.  Sometimes you must do something that’s not in the best interest of your product team, but you see that it is in the best interest of the customer and of the broader organization.

Accountability

The companion to empowerment is accountability.  Product teams are given the space and time to come up with the solutions to the problems they are assigned, but with that empowerment comes responsibility and accountability.  Accountability is directly related to ambition.  If the team was asked to be very ambitious (a moon shot) and the attempts failed to generate the desired results then that is largely expected.  If they were asked to make a high-integrity commitment and they failed to deliver, accountability comes into play.  If a team fails substantially on their team objectives, treat this in much the same way we treat an outage.  Get the product team together with a set of their peers — especially peers from any product team that were impacted by their failure — and have the team discuss what they believe was the root cause of their failure.  Explore what they believe they could — and should — have done differently.  Perhaps if they had shared with management at the first signs of a problem, they could have received help?  Perhaps the product team that was depending on them could have made other arrangements, or even helped themselves?  These lessons learned also apply to the team’s managers.  Were there signs that were missed?  Was there coaching that could have been provided earlier?  Were there questions that should have been asked by management that weren’t?

Attribution of key results with A/B test:  This isolates the contribution of just one team’s changes from everything else going on in other teams or from elsewhere across the company (e.g., marketing programs).  The second involves dividing up the various contributions to the relevant key result by channel or source (slicing).

• Mobile team:  Applications from mobile notifications
• Search team:  Applications from search results
• Recommendations team:  Applications from recommendations.

A/B tests depend on sufficient traffic to yield dependable results in a reasonable amount of time.

10 most important keys to effective team objectives

1. The most important thinking is to empower teams by assigning them problems to solve and then give the teams the space to solve them.  For them to make good decisions, they will also need you to share the strategic context, especially the product strategy.
2. We love it when product teams volunteer to work on specific objectives, and we try to accommodate this when possible to leverage their motivation and enthusiasm for the problem.  But we can’t always do so because we need to make sure we cover everything we need to.
3. Selecting the objectives to be worked on, and ultimately deciding which team or teams works on each objective, is the explicit responsibility of product leadership.   However — and this is critically important for empowerment — the key results need to come from the team.
4. It’s normal that there’s a back and forth — not that the leaders doubt or question what the teams propose as their key results, but rather judging which investments are worth the effort and associated risk.  Suppose a team believes that, with their other objectives, they can only make a very minimal improvement to a specific, important KPI.  The leaders might consider having the team focus exclusively on one objective or decide to ask a different team to pursue it.
5. There is nothing wrong with assigning the same objective to multiple teams — each team tackling the problem from its own perspective and skills.  In fact, for difficult product problems, this is a very effective technique.  On hard problems, we expect that not all teams will make the same level of progress, and we can’t anticipate in advance what the teams will learn when they each get deep into their product discovery work.
6. There is nothing wrong with asking multiple teams to collaborate on the same team objective.  Asking a platform team and an experience team to collaborate on a difficult problem is a common scenario.
7. For product teams to come up with key results, it’s essential that they understand the level of ambition you want from them.  We need to be clear with teams when we want them to be very ambitious (aka moon shot), when we want them to be conservative (aka roof shot), and when we need them to make a high-integrity commitment.
8. Product teams can only be accountable to the results if they are empowered to figure out a solution that works and if they are the ones to come up with the key results.
9. The product leaders have to realize that while team objectives are critically important, they are not the only things that the product team is working on.  Every team has some level of ongoing “keep-the-lights-on” activities.  This includes such things as fixing critical bugs, handling customer situations, and so forth.
10. Normally, these team objectives are created or updated every quarter — That gives teams enough time to make real progress, yet not too much time that the business can’t adjust to changes.  There may be occasional situations where team objectives need to change during the quarter, but these should be the exception rather than the rule.

Essence of this is having a knowledgeable leader sit down with the product team and explain the strategic context.  Then, explain the problem you need the team to solve, and how success is measured.  The key is to have this conversation, and for leaders to provide the necessary coaching, and give the product teams the space to solve the problem in the best way they see fit.  OKRs is a good technique to use.

Product organization needs to deliver the business results. Organization needs to have intentional and focused product strategy and the product teams are empowered and accountable to the results. Now the company has the product strategy, this strategy needs to be shared with the executives because that will communicate the reason for the focus, and for the decisions on what to work on. If the most important insights were first discovered by one of the key executives or stakeholders, it’s important to be generous in crediting the sources of that insight. You want to build a culture that encourages the constant seeking and leveraging of these insights.

In an empowered product team, the team is there to serve customers, with products that customers love, yet work for the business. The stakeholders are partners we need to collaborate with to come up with solutions that work (solutions that are valuable, usable, feasible and viable). The stakeholders help us with viability. We may need to sit down with a company lawyer to discuss legal constraints and the various ways we might be able to address them.

In empowered product teams working on solving hard problems, discovery techniques generate insights very frequently. We are meeting with users and customers, weekly and testing our product ideas. We are digging deeper into their context and their needs. We are analying the data from our product’s usage, and from live-data testing. We are constantly investigating new enabling technologies to see if any can help us solve the problems we are facing in new and better ways. We are tracking industry data and learnings to see if there are relevant trends. We are also constantly seeking these insights from others across the company — product marketing, sales, finance, customer success. We want to share these learnings with our colleagues in other departments. First, the insight may help them. Second, they may have additional insights while viewing the data through their lens. Thirid, they may be able to help us explain the dynamics in order to better leverage the insights. Fourth, it is imporantant that the company learn the difference between a prototype getting a bad response during discovery, and a product failing in the market. “Failing” in the market is truly failing. The type of relationship you want is one where you are sharing openly and generously. By sharing insights and learnings, you are bringing your business partners on the journey with you.

Top 10 techniques for evangelizing your products

1. Use prototypes. It will need to be a high-fidelity prototype, it would need to look realistic. This is the single most effective technique for persuation of a product idea.
2. Show the customer pain you are addressing, share quotes or put together a video montage. Bring developers or executives along for user testing. They just have to hear the customer’s words and witness their pain themselves to get it.
3. Share the vision. The product vision shows where you hope to be in 3-10 years.
4. Share the learnings. You will have significant learnings and insights from the data and from users and customers, on a fairly frequent basis. Share these learnings — not just the things that went well but share the problems too.
5. Share credit. Make sure the team, the executives, and the key stakeholders view the product as their product, not just your product. When things don’t go well, take responsibility for the miss, and show the people you’re learning from the mistakes as well.
6. Learn how to give a great demo. Especially for your executives and your stakeholders, we’re not trying to teach them how to operate the product, and we’re not trying to test whether they could use the product. We’re trying to show them the value. A demo is not training, and it’s not a test — it’s a form of sales. Get good at it.
7. Do your homework. They are more likely to follow you if they believe you know what you’re talking about. Be an expert on your users and customers, your data, your business, and your market.
8. Be genuinely excited about your product.
9. Learn to show enthusiasm. Enthusiasm is contageous.
10. Spend time with every member of the product team.

To innovate, people need autonomy and meaning. Leader needs to define what the purpose is, to make sure that everyone inside and outside the organization — including customers and partners – knows what they are doing to promote it. This purpose needs to be clear and consistently communicated in the way it is messaged, as well as consistenly reflected in every aspect of the day-to-day running of the company — from the types of hires made, to the processes used, and even to the way the office space is designed.

Inspired, Empowered, and Transformed

Great teams are made up of ordinary people who are inspired and empowered. They are inspired with ideas and techniques for quickly evaluating those ideas to discover solutions that work — that are valuable, usable, feasible, and viable. They are empowered to solve hard problems in ways their customers love, yet work for their business. Empowered teams also need strategic context that comes from the product leadership – especially the product vision and the product strategy — and the active support of their management, primarily with ongoing coaching.

The prerequisite for this transformation, to empowered product teams, is getting your CEO — to understand the necessary role of technolgy as the enabler of the business, and not just a necessary cost of doing business. Without this understanding, your chanes of success are low.

First, you’ll need to ensure you have strong product leaders in place. Without this, you won’t be able recruit and coach the necessary staff for product teams, you won’t have a solid product strategy, and you won’t earn the trust of the leaders and the stakholders. So this is really the first and most critical step.

Second, you’ll need to give those strong product leaders the ability to recruit and develop the staff required for empowered product teams. This means raising the bar on the product managers and you need to ensure that the team is staffed with people who are competent.

Third, you will need to redefine the realtionship with the business. With the empowered product team model, the idea is to be true partners with the business — collaborating to come up with solutions that customers love, yet also work for the business. Much smaller team of true missionaries will typically dramatically outperform larger teams of consultants and merceneries.

The Most Important Thing

Best single source of innovation is your engineers (because they’re working with the enabling technology every day, so they’re in the best position to see, what’s just now possible). Product vision is intended to attract and inspire these engineers. The product strategy is intended to ensure these engineers are working on the most important problems. The team objectives give the engineers clear statements of problems to solve, and the outcomes to strive for. The product manager and product designer provide critical constraints regarding business viability and customer experience, respectively. User research and data science provide the engineers with key insights. Empowerment of engineers means that you provide the engineers with the problem to solve and the strategic context, and they are able to leverage technology to figure out the best solution to the problem. If you’re just using your engineers to code, you’re only getting about half their value. Strong tech-powered product company no sooner outsources their engineers than they would outsource their CEO. The engineers are the easiest way to tell if the company has teams of missionaries or teams of merceneries. All breakthrough innovations you use and love every day originated from an empowered engineer working in an empowered team.

Your company understands the critical and essential role that technology plays in enabling your business, and the experience you provide to your customers. When new technologies emerge that you believe have the potential to be relevant, you immediately designate some engineers to learn that technology and to consider how it may be able to help solve problems for your customers in ways that are just now possible. You view your product managers, product designers, engineers, and data scientists as absolutely core to your business. You would no sooner consider outsourcing them than you would outsource your executives. You have developed and embraced a culture of coaching. Every single member of a product team has at least one manager that is committed to helping her reach her potential. You have built a reputation as a company where ordinary people who are competent and have good character can develop into a member of an extraordinary product team. Your hiring managers know that they are personally responsible for recruiting candidates, ensuring a strong interview and hiring process, and then onboarding these new people and ensuring they are successful. Strong staffing has become a core competency for your managers. You have an inspiring and compelling product vision that unites the various product teams from across the organization in a common purpose that is meaningful to your customers. This vision will likely take 3 to 10 years to fully realize, but you are consistently making progress on this vision, quarter by quarter. You have designed your team topology to optimize for empowerment and autonomy. The people on your product teams feel real ownership over a meaningul piece of the larger whole, and they understand how and when to work with their colleagues on other teams to collaborate on larger problems. You are executing on a product strategy that focuses on the most important goals and is powered by insights that come from your data and your ongoing interactions with customers. You know the most impactful problems that you need your teams to solve. These problems to solve are assinged to specific product teams with team objectives. Those teams then use product discovery techniques to figure out the tactics that can actually solve the problems, and product delivery builds that solution to bring it to market. Today, the relationship between the product teams and your business leaders and stakeholders is one of mutual respect and true collaboration. The product teams work closely with the stakeholders to come up with solutions that customers love, yet work for the business. Both the teams and the stakeholders understand and embrace this. Most important, the product teams are empowered to come up with the best solution to the problems they’ve been asked to solve, and they are accountable to the results. The engineers are constantly looking to apply new technology in new ways to better solve customer problems. The designers are continuously working to provide the necessary user experience. The product managers take responsibility for the value and the viability of the solutions. The teams are inspired and proud to be working collaboratively with skilled colleagues on meaningful problems.