Inspired (WIP)

It doesn’t matter how good your engineering team is if they are not given
something worthwhile to build.

Startups

The reality of startup life is that you are in a race to achieve product/market fit
before you run out of money. Nothing else much matters until you can come up
with a strong product that meets the needs of an initial market.
While money and time are typically tight, good startups are optimised to learn and
move quickly.

Enterprise companies
Strong tech-product companies know they need to ensure consistent product
innovation. This means constantly creating new value for their customers and their
business. Not just tweaking and optimizing existing products (referred to as value
capture) but, rather, developing each product to reach its full potential.

The root cause of failed products

The process that most companies follow:

Ideas → Biz case → Roadmap → Requirements → Design → Build → Test →

Deploy
The issues with this process:

1. The source of ideas - this model leads to sales-driven specials and

stakeholder-driven products. Another consequence is the lack of team
empowerment. In this model, they are just there to implement - they are
mercenaries.

2. Business cases - we can’t know how much money we will make because that
depends entirely on how good the solution turns out to be. The truth, however,

Inspired (WIP) 1
 is that many product ideas end up making absolutely nothing. One of the most
critical lessons in product is knowing what we can’t know. Likewise we have
no idea what it will cost to build. Without knowing the actual solution this is
extremely hard for engineers to predict.

3. Product roadmaps - The two inconvenient truths about product:

a. The first is that at least half of our ideas are just not going to work. There
are many reasons for an idea to not work out:

i. customers just aren’t as excited about this idea as we are

ii. sometimes they want to use and they try it out, but the product is so
complicated that it is simply more trouble than it is worth

iii. sometimes the issue is that the customers would love it, but it turns out
to be much more involved to build than we thought, and we decide we
simply can’t afford the time and money required to deliver it

b. The second inconvenient truth is that even with the ideas that do prove to
have potential, it typically take several iterations to get the implementation
of this idea to the point where it delivers the necessary business value.
This is called time to money.

Questions:

What are the challenges that we faced with roadmaps at Landmark group?
Think about this with the lens of how strong product teams work (see
principles below)

Why did we try to create Product roadmaps at the startup?

4. Role of product management in this model - this is more like project

management - gathering requirements and documenting them.

a. Questions:

i. If this is project management, how would product management role is

defined differently?

ii. Are there any small changes that the product managers can do on a
daily basis to make them move closer to the real product management

Inspired (WIP) 2
 role?

5. Role of design - it is too late in the game to get the real value of design, and
mostly what is being done is what we call the “lipstick on the pig” model.

a. Questions:

i. How and when should the design be involved in the process?

ii. Comparison of the working model in a startup and an enterprise

company.

6. Role of engineering - engineering gets brought in way too late. If you are just
using your engineers to code, you are only getting about half their value. The
little secret in products is that engineers are typically the best single source
of innovation, yet they are not even invited to the party in the process

7. The principles and key benefits of Agile enter far too late.

8. This entire process is very project-centric.

9. All the risk is at the end, which means that customer validation happens way
too late.

a. Question:

i. After our initial customer validation at Pixical, of what we were trying to

build, all our next iterations were based on data and our interpretation
of the data and the insights. How could we have done a better job of
learning and moving quickly?

10. The biggest loss of all usually turns out to be the opportunity cost

Principles of Strong Product Teams

Three overarching principles at work:

1. Risks are tackled up front, rather than at the end.

We tackle these risks prior to deciding to build anything. These risks include
value risk (whether the customers will buy it), usability risk (whether the
customer can figure out how to use it), feasibility risk (whether our engineers
can build what we need with the time, skills and technology we have), and

Inspired (WIP) 3
 business viability risk (whether this solution also works for the various aspects
of our business - sales, marketing etc.

2. Products are defined and designed collaboratively, rather than sequentially.

They have moved beyond the old model in which a product manager defines
requirements, a designer designs a solution that delivers on those
requirements, and then the engineering implements those requirements, with
each person living with the constraints and decisions of the ones that
preceded. In strong teams, product, design, and engineering work side by
side, in a give-and-take way, to come up with technology-powered solutions
that our customers love and that work for our business.

3. It is all about solving problems and not implementing features. Strong teams
know it is not about implementing a solution. They must ensure that the
solution solves the underlying problem. It is about business results.

Questions:

How we worked at our startup applying the above principles?

How did we violate the first and the second principles of a strong product
team at Landmark Group even though we moved to squads and implemented
agile?

Continuous Discovery and Delivery

There are two essential high level activities in all product teams:

We need to discover the product to be built, and

We need to deliver that product to market.

Discovery and delivery are both typically ongoing and in parallel

Product Discovery
Discovery is very much about the intense collaboration of product management,
user experience design, and engineering. In discovery, we are tackling the various
risks before we write even one line of production software.

Inspired (WIP) 4
 The purpose of the product discovery is to quickly separate the good ideas from
the bad. The output of product discovery is a validated product backlog.
Specifically, this means getting answers to four critical questions:

1. Will the user buy this (or choose to use it)?

2. Can the user figure out how to use it?

3. Can our engineers build this?

4. Can our stakeholders support this?

Prototypes

Product discovery involves running a series of very quick experiments, and to do

these experiments quickly and inexpensively, we use prototypes rather than
products.

We use prototypes to conduct rapid experiments in product discovery, and then in

delivery, we build and release products in hopes of achieving product/market fit,
which is a key step on the way to delivering on the company’s product vision.

The MVP should be a prototype, not a product. Building an actual product-quality

deliverable to learn. even if that deliverable has minimal functionality, leads to
substantial waste of time and money, which of course is the antithesis of Lean.

Product Teams
It’s all about the product team. So much of what we do in a strong product
organization is to optimize for the effectiveness of product teams.

We need team of missionaries, not mercenaries. Mercenaries build whatever they

are told to build. Missionaries are true believers in the vision and are committed to
solving problems for their customers.

Team reporting structure - A product team is not about reporting relationships - it

has an intentionally flat organizational structure. The people on the team typically
continue to report to their functional manager.

Inspired (WIP) 5
 Team collaboration - A product team is a set of highly skilled people who come
together for an extended period of time to solve hard business problems.

Team location - the best companies have learned the value of sitting together as a
team. There is a special dynamic that occurs when the team sits together, eats
lunch together, and builds personal relationships with one another.

Team scope - there a lots of useful ways to slice up the pie. Sometime we have
each team focus on a different type of user or customer. Sometimes each team is
responsible for a different type of device. Sometimes we break things up by
workflow or customer journey. There is never a perfect way to carve up the pie.
Team duration

Team autonomy

Why it works:
First, collaboration is built on relationships, and product teams - especially co-
located teams - are designed to nurture these relationships.

Second, to innovate you need expertise, and the durable nature of product teams
let people go deep enough to gain that expertise. Third, instead of just building
what others determine might be valuable, in the product team model the full team
understand the business objectives and context. The full team feels ownership
and responsibility for the outcome.

Questions:

What steps did we take to optimize for the effectiveness of the product teams
at Landmark? What worked and what could be improved?

Remote vs Co-located product teams?

Product Manager

The Product Manager needs to be among the strongest talent in the company. If
the product manager doesn’t have the technology sophistication, doesn't have the
business savvy, doesn't have the credibility with key executives, doesn't have the
deep customer knowledge, doesn't have the passion for the product, or doesn't
have the respect of their product team, then it is a sure recipe for failure.

Inspired (WIP) 6
 Key Responsibilities

Every business depends on customers. And what customers buy - or choose to

use - is your product. The product is the result of what the product team builds,
and the product manager is responsible for what the product team will build.

Four things that a product manager brings to a party:

1. Deep knowledge of the customer - you need to become an acknowledged

expert on the customer: their issues, pains, desires, how they think etc. This
requires both qualitative learning (why our users and customers behave the
way they do), and quantitative learning (to understand what they are doing)

2. Deep knowledge of the data - a big part of knowing your customer is

understanding what they are doing with your product.

3. Deep knowledge of your business - a deep understanding of your business

and how it works, and the role your product plays in your business. This
means knowing who your various stakeholders are and especially learning the
constraints they operate under.

4. Deep knowledge of your market and industry - this includes not only your
competitors but also key trends in technology, customer behaviors and
expectations, following the relevant industry analysts, and understanding the
role of social media for your market and customers. The industry is constantly
moving, and we must create products for where the market will be tomorrow,
not where it was yesterday.

The successful product manager must be the very best versions of smart, creative
and persistent.

Smart - intellectually curious, quickly learning and applying new technologies to

solve the problems for customers, to reach new audiences, or to enable new
business models. The passion for products and for solving customer problems is
not something you can teach.
You must take your preparation for this role very seriously:

Start by becoming an expert in your users and customers

Inspired (WIP) 7
 Work to establish a strong relationship with your key stakeholders and
business partners

Become an undisputed expert on your product and your industry

Work very hard to build and nurture the strong collaborative relationship with
your product team

Two specific academic courses that every product manager should take:

1. Introduction to computer programming

2. Introduction to business accounting/finance - the key is to make sure you gain

a big-picture understanding of how business work

** The primary product responsibility is ensuring that the engineers have a

product worth building.

Questions:

How do we develop deep understanding of the customer - qualitative and

quantitative? What are the different ways and methodologies.

What is needed to become a strong product manager?

Product Designer
Modern product designers continuously collaborate with product managers and
engineers - from discovery to delivery. UX is any way that customers and end
users realize the value provided by your product. It includes all the touch points
and interactions a customer has with your company and product over time. Good
product designers think about the customer’s journey over time as they interact
with the product and with the company as a whole. Consider these questions:

How will customers first learn about the product?

How will we onboard a first-time user and (perhaps gradually) reveal new
functionality?

Inspired (WIP) 8
 How might users interact at different times during the day?

What other things are competing for users’ attention?

How might things be different for a one-month-old customer versus a one-

year-old customer?

How will me motivate a user to a higher level of commitment to the product?

How will we create moments of gratification?

Good product designers are constantly testing their ideas with real users and
customers. They don’t just test when a prototype or idea is ready; they build
testing into their weekly cadence, so they are able to constantly validate and
refine ideas as well as collect new insights they might not have been looking for.

We need design- not just as a service to make our product beautiful - but to
discover the right product. Five keys to a successful and healthy relationship with
your designer:

1. Do whatever you need to do to have your designer sit next to you.

2. Include your designer from the very inception of every idea.

3. Include your designer in as many customer and user interactions as possible.

Learn about the users and customers together.

4. Fight your temptation to provide your designer with your own design ideas.

5. Encourage your designer to iterate early and often.

The bottom line is that you and your designer really are partners. You are there to
discover the necessary product solutions together, and you each bring different
and critical skills to the team.

Questions:

How to collaborate with product design and engineering team in discovery?

Inspired (WIP) 9
 The Engineers
There is probably no more important relationship for a successful product
manager than the one with your engineers. This strong relationship begins with
you. You need to do your homework and bring to the team the knowledge and
skills of good product management. It is also hugely important that you have an
actual appreciation for the demands and complexities of the engineering job.
There are typically two types of discussions going on each day with your
engineers:

1. You are soliciting their ideas and input for the items you are working on in
discovery.

2. They are asking you clarifying questions on the items they are working on
delivering to production.

Tech lead also has an explicit responsibility to help the product manager and
product designer discover a strong solution.

Questions:

1. How do you work with tech lead for product discovery?

Product Marketing Managers

In the best tech product companies, product marketing plays an essential role in
discovery, delivery and ultimately go-to-market, which is why they are important
members of the product team. Coming up with winning products is never easy.
We need a product that our customers love, yet also works for our business.
However, a very large component of what is meant by works for our business is
that there is a real market there (large enough to sustain a business), we can
successfully differentiate from the many competitors out there, we can cost-
effectively acquire and engage new customers, and we have the go-to-market
channels and capabilities required to get our product into the hands of our
customers.

Inspired (WIP) 10
 Modern product marketing managers represent the market to the product team -
the positioning, the messaging, and a winning go-to-market plan. They are deeply
engaged with the sales channel and know their capabilities, limitations, and
current competitive issues.

User Researchers
When we talk about how we do product discovery, we are continuously doing two
kinds of rapid learning and experimentation.

1. Qualitative - with qualitative learning some of our research is

a. generative - which is understanding the problems we need to solve

b. evaluative - which is assessing how well our solutions solve the problem

2. Quantitative

User researchers are trained in this range of qualitative techniques. They can help
you find the right type of users, craft the right types of tests, and learn the most
from each user or customer interaction.

Data analysts
For quantitative learning, data analysts help teams collect the right sort of
analytics, manage data privacy constraints, analyze the data, plan live-data tests,
and understand and interpret results.

Test Automation Engineers

People @ Scale
The primary job of leadership in any technology organization is to recruit, to
develop, and to retain strong talent. However, in a product company, the role goes
beyond people development and into what we call a holistic view of the product.

Leaders of Product Management

Inspired (WIP) 11
 To ensure a holistic view of how the entire system fits together from a business
point of view (product vision, strategy, functionality, business rules, and business
logic), we need either the leaders of the product management organization (VP
product, directors of product), or a principal product manager. This person should
regularly review the work of the various product managers and product teams,
identifying and helping to resolve conflicts.

Leaders of Product Design

These leaders must ensure a consistent and effective user experience

systemwide.

Leaders of Technology
To ensure a holistic view of how the entire system fits together from a technology
point of view, we have a technology organization leader (CTO or VP of
engineering)

Have these three people sit very close to one another, sometimes in the same
physical office.

The Head of Product Role

Great product leaders are highly valued and often go on to found their own
companies.

Competencies - specifically, you are looking for someone who has proven to be
strong in four key competencies:

1. team development - the single most important responsibility of any VP of

product is to develop a strong team of product managers and designers. This
means making recruiting, training and ongoing coaching the top priority.
Realize that developing great people requires a different set of skills than
developing great products. For this position, you need to ensure you hire
someone who has a proven ability to develop others. They should have a track
record of identifying and recruiting potential talent and then working actively

Inspired (WIP) 12
 and continuously with those people to address their weaknesses and exploit
their strengths.

2. product vision and strategy

3. execution - no matter where the vision comes from, all the great vision in the
world doesn’t mean much if you can’t get the product idea into the hands of
customers. You need a product leader who knows how to get things done. The
product leader should be an expert in modern form of product planning,
customer discovery, product discovery, and product development process.

4. product culture - a strong product culture means that the team understands
the importance of continuous and rapid testing and learning. They understand
that they need to make mistakes in order to learn, but they need to make them
quickly and mitigate the risks.

The Head of Technology Role

The hallmark of a great CTO is a commitment to continually strive for technology

as a strategic enabler for the businness and the products. His job is also to make
sure that members of the senior engineering staff are participating actively and
contributing significantly throughout product discovery.

The Delivery Manager Role

They are all about helping the team to get stuff live faster, not by cracking the
whip but by removing obstacles that get in the way.

Principles of Structuring the Product Teams

One of the most difficult issues facing every product organization at scale is just
how to split up your product across your many product teams. Some principles
can be considered:

1. Alignment with investment strategy - you need to have an investment strategy,

and your team structure should be a reflection of that.

Inspired (WIP) 13
 2. Minimize dependencies - this helps teams move faster and feel much more
autonomous.

3. Ownership and autonomy - one of the most important traits of product teams
is that we want teams of missionaries and not teams of mercenaries. This
leads directly to the concepts of ownership and autonomy. A team should feel
empowered, yet accountable for some significant part of the product offering.

4. Maximize leverage - as organizations grow, we often find common needs and

the increased importance of shared services. We do this for speed and
reliability. We don’t want every team reinventing the wheel. Realize, however,
that creating shared servvices also creates dependencies and can impinge on
autonomy.

5. Product Vision and strategy - the product vision describes where we as an

organization are trying to go, and the product strategy describes the major
milestones to get there. Once you have your product strategy and vision,
ensure you have structured the teams to be well positioned to deliver on them.

6. Team size - it is really difficult for one product manager and product designer
to keep more than about 10-12 engineers busy with good stuff to build. Also,
it’s important that each product team have one, and only one, product
manager.

7. Alignment and architechture

8. Alignment with users or customer.

9. Alignment with business.

10. Structure is a moving target - realize that the optimal structure of the product
organization is a moving target. The organization’s needs should and will
change over time. There is never a perfect way to structure a team - every
attempt at structuring the organization is a perfect will be optimized for some
things at the expanse of others.

** There is no such thing as over-communication. Lea tackled these concerns and

more head-on with a clear and compelling vision and strategy and clear and
continuous communication to the many stakeholders.

Inspired (WIP) 14
 The Right Product
Product Roadmaps
Typical product roadmaps are all about output. Yet, good teams are asked to
deliver business results. Product roadmap is defines a prioritized list of features
and projects your team has been asked to work on. These product roadmaps are
usually done on a quartely basis. In some cases, product roadmaps come down
from management and sometimes from the product manager. They do normally
contain the requested features, projects, and big multi-team efforts often called
initiatives. And they typically include due dates or at least time frames for when
each item is expected to be delivered.
Management has fair reasons for wanting product roadmaps:

they want to be sure you’re working on the highest-value things first.

they are trying to run a business, which means they need to be able to plan

These are reasonable desires. Yet, typical roadmaps are the root cause of most
waste and failed efforts in product organizations.

The problems with Product Roadmaps

The reasons for this are the two inconvenient truths about product:

at least half of our product ideas are just not going to work for various reasons
(check above)

even with the ideas that do prove to be valuable, usable, feasible and viable, it
typically takes several iterations to get the execution of this idea to the point
where it delivers the expected business value - time to money.

Strong product teams understand these truths and embrace them. They are good
at quickly tackling the risks and are fast at iterating to an effective solution. This is
what product discovery is all about.
The issue is that anytime you put a list of ideas on a document entitled “roadmap”,
no matter how many disclaimers you put on it, people across the company will
interpret the items as a commitment. And that is the crux of the problem - now you

Inspired (WIP) 15
 are committed to building and delivering this thing, even when it doesnt solve the
underlying problem.

The Alternatives to Product Roadmaps

In the empowered product team model, the teams are themselves equipped to
figure out the best ways to solve the particular business problems assigned to
them. The product teams need to have the necesary business context. They need
to have a solid understanding of where the company is heading and they need to
know how their particluar team is supposed to contribute to the larger purpose.
For technology companies, two main components provide this business context:

1. The product vision and strategy

2. The business objectives - specific, prioritized business objectives for each

product team. The idea behind business objectives is simple enough: tell them
what you need them to accomplish and how the results will be measured, and
let the team figure out the best way to solve the problems. It is the
management’s responsibility to provide each product team with the specific
business objective they need to tackle.

There a few product teams that have modified their product roadmaps so that
each item is stated as a business problem to solve rather than the feature or
project that may or may not solve it. These are called outcome-based roadmaps.

High-integrity commitments
The key is to understand that the root cause of all this grief about commitments is
when these commitments are made. They are made too early. In continuous
discovery, we ask the executives and our other stakeholders to give us a little time
in product discovery to investigate the necessary solution. We need the time to
validate that solution with customers to ensure it has the necessary value and
usability, with engineers to ensure its feasibility, and with stakeholders to ensure it
is viable for our business. Once we have come up with a solution that works for
our business, we now can make an informed an high-integrity commitment about
when we can deliver and what business results we can expect.

Inspired (WIP) 16
 Questions:

What are the different ways of doing product roadmaps? What are the typical
problems with product roadmaps?

Product Vision and Product Strategy

The Product Vision
The product vision describes the future we are trying to create, typically
somewhere between two and five years out. In truth, buying into a vision is always
a bit of a leap of faith. You likely don’t know how, or even if, you’ll be able to
deliver on the vision.
Principles of Product Vision:

1. Start with why - the central notion here is to use the product vision to
articulate your purpose.

2. Fall in love with the problem, not with the solution

3. Don’t be afraid to think big with vision

4. Don’t be afraid to disrupt yourselves because, if you don’t, someone else will

5. The product vision needs to inspire

6. Determine and embrace relevant and meaningful trends

7. Skate to where the puck is heading, not where it was

8. Be stubborn on vision but flexible on the details - it is very much possible that
you may have to adjust course to reach your desired destination. That’s called
a discovery pivot

9. Realize that any product vision is a leap of faith

10. Evangelize continuously and relentlessly

The Product Strategy

Inspired (WIP) 17
 The product strategy is the sequence of products or releases we plan to deliver
on the path to realizing the product vision. For most types of businesses, I
encourage teams to construct product strategies around a series of
product/market fits.

For business-focused companies, you might have each product/market fit

focus on a different vertical

For consumer-focused companies, we often structure each product/market fit

around a different customer or user persona.

Sometimes, the product strategy is based on geography, where we tackle

different regions of the world in an intentional sequence. There is no single
approach to product strategy that is ideal for everyone. The most important
benefit is just that you decided to focus your product work on a single target
market at a time. The path to achieving the product vision is the product strategy.
The difference between vision and strategy is analogous to the difference
between good leadership and good management. The product vision should be
inspiring and the product strategy should be focused.

Principles of Product Strategy:

1. Focus on one target market or persona at a time

2. Product strategy needs to be aligned with Business Strategy

3. Product strategy needs to be aligned with sales and go-to-market strategy

4. Obsess over customers, not over competitors

5. Communicate the strategy across the organization

Prioritizing markets
There are three critical inputs to prioritize your markets:

1. Total addressable market (TAM)

2. Distribution or Go to Market (GTM) - different markets may require differnt

sales channels and go-to-market strategies

Inspired (WIP) 18
 3. Time to Market - how long it will take

Product Principles
Where the product vision describes the future you want to create, and product
strategy describes your path to achieving that vision, the product principles speak
to the nature of the products you want to create. The principles are aligned with
the product vision for an entire product line.

Product Objectives
It is based on two fundamental principles:

1. Never tell people how to do things. Tell them what to do, and they will surprise
you with their ingenuity

2. When performance is measure by results

The OKR technique

It is a tool for management, focus and alignment. Key points to keep in mind:

Objectives should be qualitative; key results need to be

quantitative/measurable.

Key results should be a measure of business results, not outputs or tasks.

Focus on the organization’s objective and the objectives for each product
team, which are designed to roll up and achieve the organization’s objectives

Find a good cadence for your organization.

Keep the number of objectives and key results for the organization and for
each team small.

Every product team must track their active progress agains their objectives

The objectives should cover what the team needs to accomplish.

It is important, that teams feel accountable to achieving their objectives.

Inspired (WIP) 19
 Agree as an organization how you will be evaluating or scoring your key
results.

Senior management is responsible for the organization’s objectives and key

results.

Product team Objectives

If you deploy OKRs for your product organization, the key is to focus your OKRs at
the product team level.

Product Objectives at Scale

What needs to change as you use the OKR system at scale:

1. The first step is a very clear understanding of the organization-level

objectives.

2. At scale, it is very common to have a significant number of product teams that

are there in support of the other product teams. The leadership will need to
help coordinate the objectives for these teams and make sure we coordinate
the dependencies and align the interests.

3. Once you have your objectives, there is a very critical reconciliation process in
which the leadership team looks at the proposed key results from the product
teams and identifies gaps and then looks to what might be adjusted to cover
those gaps.

4. At scale, it is much harder to know what product teams are working on which
objectives and the progress they are making. We lean on management to help
connect the dots.

5. The larger the organization, the longer the list of high-integrity commitments
that are needed and the more actively they need to be managed and tracked.

6. In case there are multiple business units, then there would be corporate-level
OKRs and there would also be business unit-level OKRs.

Product Evangelism

Inspired (WIP) 20
 It is “selling the dream”. It is heloing people imagine the future and inspiring them
to help create the future. Top 10 pieces of advice for product managers to sell the
dream:

1. Use a prototype

2. Share the pain: show the team the customer pain you are addressing.

3. Share the vision: make sure you have a very clear understanding of your
product vision, product strategy, and product principles.

4. Share learning generously

5. Share credit generously

6. Learn how to give a great demo: we are trying to show them the value of what
we are building. A demo is not training, and it is not a test. It is a persuasive
tool.

7. Do your homework: your team and your stakeholders will all be much more
likely to follow you if they believe you know what you are talking about. Be the
undisputed experts on your users and customers.

8. Be genuinely excited

9. Learn to show some enthusiasm

10. Spend time with your team.

The Right Process

Product Discovery
For most teams, there are two very significant challenges to tackle:

1. Discovering in detail what the customer solution needs to be. That includes
everything from making sure there are enough customers that even need this
solution and then coming up with a solution that works for our customers and
for our business.

2. We need to ensure we deliver a robust and scalable implementation that our

customers can depend on for consistently reliable value.

Inspired (WIP) 21
 We need to learn fast, yet also release with confidence.
If you want to discover great products, it really is essential that you get your ideas
in front of real users and customers early and often.

Principles of Product Discovery

The purpose of product discovery is to make sure we have some evidence that
when we ask the engineers to build a production-quality product, it won’t be a
wasted effort. Much of the key to effective product discovery is getting access to
our customers without trying to push our quick experiments into production. The
purpose of product discovery is to address these critical risks:

Will the customer buy this, or choose to use it? (Value risk)

Can the user figure out how to use it? (Usability risk)

Can we build it? (Feasibility risk)

Does this solution work for our business? (Business viability risk)

Principles:

1. We know we can’t count on our customers (or our executives) to tell us what
to build. It is our job to make sure that the solution we deliver solves the
underlying problem.

2. The most important thing is to establish compelling value. It is all hard, but the
hardest part of all is creating the necessary value so that customers ultimately
choose to buy or use.

3. Coming up with a good user experience is usually even harder, and more
critical to success

4. Functionality, design, and technology are inherently intertwined

5. We expect that many of our ideas won’t work out, and the ones that do will
require several iterations

6. We must validate our ideas on real users and customers.

Inspired (WIP) 22
 7. Our goal in discovery is to validate our ideas the fastest, cheapest way
possible.

8. We need to validate the feasibility of our ideas during discovery, not after.

9. We need to validate the business viability of our ideas during discovery, not
after.

10. It is about shared learning.

Discovery Techniques
The way to think about discovery is that we only validate what we need to, and
then we pick the right technique based on the particular situation.
There are techniques for these following activities:

Discovery framing

Discovery planning

Discovery ideation

Discovery prototyping

Discovery testing

Testing feasibility

Testing usability

Testing Value

Testing business viability

Transformation

Discovery Framing Techniques

There are two goals here:

1. To ensure the team is all on the same page in terms of clarity of purpose and
alignment. In particular, we need to agree on the business objective we’re
focused on, the specific problem we intend to solve for our customers, which

Inspired (WIP) 23
 user or customers you are solving that problem for, and how you will know if
you have succeeded.

2. To identify the big risks that will need to be tackled during the discovery work.

** If the product manager, designer, and tech lead do not feel there is a significant
risk in any of the above areas, then normally we would just proceed to delivery -
fully realizing there is a chance the team will occasionally be proved wrong. We
like to use our discovery time and validation techniques for those situations in
which we know there is a significant risk, or where members of the team disagree.

Techniques:

1. Opportunity assessment

2. Customer letter

3. Startup Canvas

** Fall in love with the problem, not the solution. More often than not, our initial
solutions don’t solve the problem - at least not in a way that can power a
successful business.
A small amount of time upfront framing the problem to be solved - and
communicating this framing - can make a dramatic difference in the results.

Opportunity Assessment Technique

The idea is to answer four key questions about the discovery work you are about
to undertake:

1. What business objective is this work intended to address? (Objective)

2. How will you know if you have succeeded? (Key results)

3. What problem will this solve for the customer? (Customer problem)

4. What type of customer are we focused on? (Target market)

Inspired (WIP) 24
 For smaller and more typically sized efforts, the opportunity assessment is usually
sufficient.

Customer Letter Technique

When embracing on a somewhat larger effort, there may in fact be multiple
reasons, several customer problems to be solved, or business objectives to be
tackled. For this size of effort, we go with Customer Letter technique.
The idea is that you describe the benefits in the format of a customer letter written
from the hypothetical perspective of one of your product’s well-defined user or
customer personas. The letter - sent to the CEO from a very happy and impressed
customer - explains why he or she is so happy and grateful for the new product or
redesign. The customer describes how it has changed or improved his or her life.
The letter also incluses and imagined congratulatory response from the CEO to
the product team explaining how this has helped the business.

Startup Canvas Technique

This technique is for especially difficult situations. This could be an early-stage
startup, where you are trying to figure out a new product that can power a
business. In this situation, you have a much broader set of risks, including
validating your value proposition, figuring out how you intend to make money, how
you plan to get this product out to your customers and sell to them, how much it
will cost to product and sell this product, and what you will measure to track your
progress.
The Biggest Risk
The startup canvas helps to quickly highlight the key assumptions and major risks
facing a startup or a significant new product in an existing. The idea is to tackle
the biggest risks first.

Inspired (WIP) 25
 Discovery Planning Techniques
Two of the techniques:

Story maps

Customer discovery program

Story Map Technique

The origin of story maps came from frustration with the typical flat backlog of
user stories. There is no context, just a prioritized list of stories. How can the team
know how one story fits in with the big picture?

Inspired (WIP) 26
 Story maps are two-dimensional maps, in which major user activities are arrayed
along the horizontal dimension, loosely ordered by time from left to right. Along
the vertical dimension, we have a progressive level of detail. As we flesh out each
major activity into sets of user tasks, we add stories for each of those tasks. The
critical tasks are higher vertically than the optional tasks. Now, each story has
context. The entire team can see how it fits with other stories. The team can also
see how the system is expected to grow over time. As we finalize our discovery
work and progress into delivery, the stories from the map move right into the
product backlog.

Customer Discovery Program Technique

Reference customer - this is a real customer (not friends or family), who is running
your product in production (not a trial or prototype), who has paid real money for
the product (it wasn’t given away to entice them to use it), and, most important,
who is willing to tell others how much they love your product (voluntarily and
sincerely).
Without the reference customers, it is very hard for the sales team to know where
the real product-market fit is. The customer discovery program technique is
designed to produce these reference customers. We are discovering and
developing a set of reference customers in parallel with discovering and
developing the actual product. I consider it the single best leading indicator of
future product success.
You would not do this program for small efforts like features or minor projects.
This is for larger efforts. Examples - creating a new product or business, taking an
existing product to a new market or new geography or redesign of a product.
The basic driver behind this technique is that, with a significant new product, the
most common objection is that prospective customers want to see that other
companies, like themselves, are already successfully using the product. They
want to see the reference customers.
We don’t want to turn on the sales or marketing machine until we have evidence
that we can help them be successful, and the reference customers are our best
evidence.

Inspired (WIP) 27
 The concept behind this technique is to focus on developing this set of reference
customers for a specific target market, which then makes it easy for sales to go
after those specific types of customers. Once we have those reference customers
for that initial target market, we can move on to expanding the product to meet the
needs of the next target market.

Recruiting The Prospective Reference Customers

We are looking for prospective customers that truly feel the pain and are near
desperate for the solution we want to build. They need to be willing to spend time
with the product team, testing out early prototypes and helping the team ensure
the product works well for them. Your job is to deep dive with each of these
customers and identify a single solution that works well for all of these customers.
Think of these early prospective customers as development partners. You are in
this together.

This technique is not designed to discover the necessary product - that comes
next. Rather, it is designed to give you direct access to the target customers
where you will find the product ideas necessary to generate reference customers.

Defining Product/Market Fit

Product/market fit shows up in terms of happier customers, lower churn rates,
shortened sales cycles, and rapid organic growth. But the threshold for any of
these can be tough to define. One technique - Sean Ellis Test.
Survey your users and ask them how they would feel if they could no longer use
this product. The general rule of thumb is that if more than 40% of the users
would be “very disappointed”, then there is a good chance you are at
product/market fit.

Discovery Ideation Technique

How do we generate the types of ideas that are likely to truly help us solve the
hard business problems that our leaders have asked us to focus on right now?

Inspired (WIP) 28
 Customer Interviews
This is one of the most powerful and important skills for any product manager and
very often the source or inspiration for many breakthrough product ideas. Here is
what I am always trying to understand:

Are your customers who you think they are?

Do they really have the problems you think they have?

How does the customer solve this problem today?

What would be required for them to switch?

Here are some of the tips for getting the most out of these learning opportunities:

Frequency - establish a regular cadence of customer interviews. This should

not be a once-in-a-while thing. A bare minimum would be 2-3 hours of
customer interviews per week, every week.

Purpose - you are not trying to prove anything during these interviews. you
are trying to understand and learn quickly. this mindset is critical and needs to
be sincere.

Recruiting users and customers - be sure to talk primarily to people in your

target market. you are looking for about an hour of their time.

Location - it is always amazing to see customers in their native habitat. there is

so much to learn just by observing their environment. But it is also fine to meet
them somewhere convenient.

Preparation - be clear beforehand what problem it is you think they have, and
think about how you will confirm or contradict that.

Who should attend - three people: product manager, the product designer, and
one of the engineers from the team. Usually the designer drives (because they
have usually been trained how to do this well), the product manager takes
notes, and the developer observes.

Interview - work to keep things natural and informal, ask open-ended

questions, and try to learn what they are doing today (not so much what they

Inspired (WIP) 29
 wish they were doing)

Afterward - debrief with your colleagues to see if you have all heard the same
things and had the same learnings.

Concierge Test Technique

A concierge test helps in quickly generating high-quality product ideas and, at the
same time, working on developing the customer understanding and empathy that
is so important for motivating the team and delivering strong solutions.
The idea is that we do the customer’s job for them - manually and personally. Just
as if you went to a hotel concierge and asked if he could find you some theatre
tickets to a popular show. You don’t really know the details of what that concierge
is doing for you to get those tickets, but you do know that he is doing something.

A concierge test requires going out to the actual users and customers and asking
them to show you how they work so that you can learn how to do their job, and so
that you can work on providing them a much better solution.

The Power of Customer Misbehavior

This technique is to allow, and even encourage, our customers to use our
products to solve problems other than what we planned for and officially support.
If you find your customers using your product in ways you didn’t predict, this is
potentially very valuable information. Dig in a little and learn what problem they
are trying to solve and why they believe your product might provide the right
foundation. Do this enough and you will soon see patterns and, potentially, some
very big product opportunities.

Hack Days
Two main types of hack days - directed and undirected.
Undirected hack day - people can explore whatever product ideas they like, so
long as it is at least loosely related to the mission of the company.
Directed hack day - there is a customer problem or business objective we have
been assigned and we ask people from the product teams to self-organize and

Inspired (WIP) 30
 work on any ideas they like that might address this objective.

Discovery Prototyping Techniques

Different types of prototypes:

Feasibility Prototypes - these are written by engineers to address technical

feasibility risks during product discovery - before we decide whether
something is feasible.

User Prototypes - these are simulations. There is a wide spectrum of user

prototypes - from those intentionally designed to look like wireframes
sketched out on paper (referred to as low-fidelity user prototypes) all the way
up to those that look and feel like the real thing (referred to as high-fidelity
user prototypes).

Live-data prototypes - the main purpose of a live-data prototype is to collect

actual data so we can prove something, or at least gather some evidence -
normally to find out whether an idea really works. this typically means two
things:

we need the prototype to access our live data sources, and

we need to be able to send live traffic - in enough quantity to get some

useful data - to the prototype

Hybrid prototypes - which combine aspects of other prototypes

Principles of Prototypes

Questions
What are the different ways of generating ideas - brainstorming, customer
interviews, concierge technique, hack days, combining information from lean
UX and sprint

Inspired (WIP) 31
 What was the definition of product/market fit for us and what all did we do to
achieve that?

What are some things I learned about learning and moving quickly in a
startup?

How can this be applied to a growth stage company or an enterprise

company?

If we can’t know how much value or money something will make and how
much is it going to cost, why do we get into the business cases for each item
in the product roadmap?

How can we create better roadmaps?

Is there a way we can get closer to answering the two questions for business -
how much value and how much cost?

How to do we reduce the value risk i.e. Will the customer buy this, or choose
to use it?

Inspired (WIP) 32