Product Management 101: Techniques for Success

Product Management 101: Techniques for Success
By Brian Kissel
Note: I have enabled “comment” access to this document, so please feel free to add your suggestions and share
this document with your friends and colleagues (https://goo.gl/yFFrml).
Table of Contents
Resources
General Overview
The Role of Product Management
Characteristics of Great Project and Product Managers
Problem Space and Solution Space
Customer Personas
User Stories
Product Documentation
Agile Product Development
Succeeding with Agile from The Lean Playbook
Analytics, Customer Engagement, & Monetization
Pricing Strategies
Overall Leadership and Organizational Development
Final Guidelines and Recommendations
Resources
The following is a summary of resources, concepts, and best practices for product managers, especially for
software as a service (Saas) product offerings. It is based on outstanding research and recommendations from a
number of thought leaders in the industry. The primary resources include the following. Each of these resources
in turn reference a number of resources in their publications.
● Pragmatic Marketing: The Pragmatic Marketing Framework
● Marty Cagan of Silicon Valley Product Group: Inspired: How to Create Products Customers Love
● Dan Olsen of Olsen Solutions: The Lean Product Playbook: How to Innovate with Minimum Viable
Products and Rapid Customer Feedback.
● Henrik Kniberg: Agile Product Ownership in a Nutshell
○ See executive summary here.
● Geoffrey Moore:
○ Crossing the Chasm (moving from early adopters to mass market adoption)
○ Dealing with Darwin (SlideShare executive summary, especially good for companies and products
in transition from initial success after “crossing the chasm” when growth slows and/or
competition becomes more significant)
I strongly encourage referring to these reference resources for more detail and context.
General Overview
● Product Manager (PM) priorities need to support corporate strategy and positioning. These priorities
need to be broadly communicated and understood by all stakeholders as they help in deciding not only
what to do, but what not to do.
● Focus on end to end business solutions, not tools or platforms
Page 1 of 27

o “Customers buy experiences and outcomes, not tools and technology”
o Understand your customer’s customer needs (B2B2C)
● “Building the right product” comes before “building the product right” – requires market validation
o Define “where we compete” and “how we win” as well as where we don’t compete
o Involves market needs and competitive analysis, problem/solution spaces, personas/use cases,
differentiators, client ROI metrics, etc.
● Specifications need to enable Engineering to “build the product right”
o Combination of documents and annotated prototypes
▪ Maximize the use of mockups (microframes, low fidelity wireframes, then high fidelity
mockups); document personas, use cases, business logic
o Format and detail should be driven by the needs of the development team (just enough to get the
job done and no more)
o Test driven design (TDD) to ensure acceptance criteria are clear
o Engineering should be involved throughout the process
▪ To guide on feasibility and resource implications
▪ To understand customer needs in partnering to define solutions
▪ To guide and understand the intent of specifications
● More than features drives market success
o Brand, rate of innovation, UX, deployability, supportability, reliability, emotional connection (fear,
greed, anger, stress, control), cost reduction, etc.
o Too many features can actually degrade the product – focus impact on “jobs to be done”
o Upgrades and enhancements should not be overly disruptive to customers
● Think modules, not features
o Rather than add more features to a product, always be thinking of the next module of
functionality that you can charge for or that will serve another persona/use case/buyer.
● Engage UX earlier and throughout the lifecycle
o Interaction through mockups (wireframes)
o Visual through high fidelity prototypes
o UX includes information architecture, interactive design, visual design. Good summary of these
roles by analogy to designing a home is here.
● Get engineers in front of users/customers
o Be selective, engineering capacity is our crown jewel
o Product development engineering hours typically have 4X the financial impact and therefore
hurdle rate as professional service engineering hours
● How PM helps engineering:
o Focus on MVP (minimum viable product) – avoid feature creep/bloat
o Keep engineering involved through the process, no “over the wall”
o Minimize churn during development, be prompt and decisive - never disrupt a sprint
o Provide sufficient “set aside capacity” for rewrites, refactoring, scalability, etc. 20% is ideal but
hard to maintain
● Use consistent frameworks and definitions where possible
o Pragmatic Marketing Framework, Silicon Valley Product Group (Marty Cagan – Inspired), Dan
Olsen “Lean Product Playbook,”280 Group “Lean Product Management,” etc.
o RACI roles if appropriate (responsible, accountable, consulted, informed)
● Product and Design principles are important “guardrails” for making decisions
o Product: low cost, high performance, flexible, comprehensive, simple, etc.
o Design: “well lit path,” “progressive disclosure,” “contextual cues”
● Product Council
Page 2 of 27

o PM, UX, Engineering, Marketing, Sales, PS, CS, Siteops
o Most important w/ product strategies and roadmaps, opportunity assessment (revenue and
costs), sharing user testing feedback, launch plans, lifecycle management
● Establish charter customers (market validation), launch partners, customer advisory board (CAB), Exec
Council, etc.
● Crowdsourcing ideas and prioritization can sometimes be helpful (IdeaScale, UserVoice, GetSatisfaction,
Jive, Salesforce all have tools), but ultimately product owners need to apply business judgement and
make the decisions.
Summary comparing strong and unperforming PM teams from Marty Cagan of SVPG
Strong Teams Underperforming Teams
Have a compelling product vision that they pursue with a missionary-
like passion
Are mercenaries
Celebrate when they achieve a significant impact to the business KPI’s
Celebrate when they finally release
something
Get their inspiration and product ideas from their scorecard KPI’s, from
observing customers struggle, from analyzing the data customers
generate from using their product, and from constantly seeking to
apply new technology to solve real problems
Gather requirements from sales and
customers
Understand who each of their key stakeholders are, they understand
the constraints that these stakeholders operate in, and they are
committed to inventing solutions that work not just for users and
customers, but also work within the constraints of the business
Gather requirements from stakeholders
Engage directly with end-users and customers every week, to better
understand their customers, and to see the customer’s response to
their latest ideas
Think they are the customer
Obsess over their reference customers Obsess over competitors
Are skilled in the many techniques to rapidly try out product ideas to
determine which ones are truly worth building
Hold meetings to generate prioritized
roadmaps
Are constantly trying out new ideas in order to innovate, but doing so
in ways that protect the revenue and protect the brand
Are still waiting for permission to run a
test
Love to have brainstorming discussions with smart thought-leaders
from across the company
Get offended when someone outside
their team dares to suggest they do
something
Have product, design and engineering sit side-by-side, and embrace the
give and take between the functionality, the user experience and the
enabling technology
Sit in their respective functional areas,
and ask that others make requests for
their services in the form of documents
and scheduling meetings
Insist they have the skill sets on their team necessary to create winning
products, such as strong interaction design
Don’t even know what interaction
designers are
Page 3 of 27

Ensure that their engineers have time to try out the discovery
prototypes every day so that they can contribute their thoughts on
how to make the product better
Show the prototypes to the engineers
during sprint planning so they can
estimate
Know that many of their favorite ideas won’t end up working for
customers, and even the ones that could will need several iterations to
get to the point where they provide the desired outcome
Just build what’s on the roadmap and
are satisfied with meeting dates and
ensuring quality
Understand the need for speed and how rapid iteration is the key to
innovation, and they understand this speed comes from the right
techniques and not forced labor
Complain they are slow because their
colleagues are not working hard enough
Instrument their work so that they can immediately understand how
their product is being used and make adjustments based on the data
Consider analytics and reporting a “nice
to have”
Integrate and release continuously, knowing that a constant stream of
smaller releases provides a much more stable solution for their
customers
Test manually at the end of a painful
integration phase and then release
everything at once
Make high-integrity commitments after they’ve evaluated the request
and ensured they have a viable solution that will actually work for the
customer and the business
Complain about being a sales-driven
company
People
● Clear roles for Product Managers (PM), Product Marketing Managers (PMM), User Experience (UX -
Information Architecture, Interaction and Visual Design), Project Managers. Use Pragmatic Marketing
Framework buckets as a starting point (see below), modify for the needs of the company
o With defined roles, KPIs and required skills become more clear
● PMs need to champion their products/domains, be the business owners
● VP PM needs to own building the team, overall product strategy & roadmap, resolving conflict, enabling
team members, and communicating with exec leadership and all stakeholders
o Enabling and mentoring existing team - personally rotate through feature team meetings, 3rd
party training (Pragmatic Marketing, Meetups, community benchmarking, Dan Olsen sessions,
Marty Cagan - Inspired, etc.), off-site sessions, etc.
o Identify and remove barriers - what processes or technologies are limiting the PM team from
being successful/impactful
o Defining and enforcing the RACI (responsible, accountable, consulted, informed) model
o Adding capacity/skills where needed, make the business case for additional resources and training
● Remote development teams: Use F2F, video, regular checking in, soliciting candid feedback, fly folks
bidirectionally from remote offices, adjust meeting times to favor different groups on a rotating basis
● Measurements: financial & MBO goals, product line profitability, net promoter score (0-10), Survey.io
(how would you feel… 1-4)
● Leverage Sales Engineers (SEs), engineers, customer support folks, etc. in PM/PMM/UX
● Always need to refresh skills and tools, it’s a fast moving market
● Problem solving
o Get folks on the same page w.r.t. overall goals, priorities, personas/use cases, cost/benefit,
customer needs
o Speak with data, not emotion
o Be transparent with all stakeholders on priorities and process
Page 4 of 27

Tools and Technology – standardize where possible, based on the needs of the groups
● Feature/Bug tracking: Jira, VersionOne, Redmine, etc.
● Product Planning: Jira Portfolio, Accept360, RallyDev, Accompa, LeanKit, Asana, Trello, GreenHopper, etc.
● WireFrames and hi-fidelity prototypes Balsamiq, Axure, Justinmind, iRise, InVision, Marvel, etc.
● Resource planning and management: Google Sheets or module in Agile tool (Jira Portfolio for example)
● Market research
o Feasibility, Usability, and Value testing (Olsen Ramen UX testing, UserTesting/UserZoom/
Validately, SurveyMonkey/Google Forms, Creative Good (Listening Labs), UE Group, etc.
o Surveys (Google Forms, SurveyMonkey, LimeSurvey, Qualtrics, etc.)
o Website analytics (Omniture, WebTrends, Google, Totango, etc.)
o A/B testing (Optimizely, Monetate, Maxymizer)
● Note: Tools need to support strategy, innovation, and execution - not the other way around. You should
use enough tools, structure, and processes to deliver the desired results predictably, consistently, and
efficiently. Don’t become a slave to your tools and don’t presume that you need to use all the same tools
and processes across all teams and initiatives. Use the right tools for the right teams and projects at the
right time. On the flip side, recognize that as your product footprint expands and your company grows,
you will need to invest in tools and process to scale your business, so be prepared to invest in these areas
as you grow. A good example of this is using Jira Portfolio, a module for Jira, that helps with resource
planning, what if analysis, and most importantly aligning your development capacity and initiatives to the
strategic priorities of the company. Jira Portfolio allows you to organize your initiatives hierarchically
from business objectives, to milestones, user stories, use cases, and engineering tasks.
Product Roles
● Product Manager (PM) has key responsibilities:
o Assessing product opportunities
o Defining the product to be built - empower the development and testing teams
o Validating product with real customers and prospects
o Owns business success
o Characteristics:
▪ Customer empathy and respect
▪ Product passion
▪ Creative problem solving, tenacity
▪ Communications - inbound/outbound, upward/downward, cross-functional
▪ Confidence, focus and work ethic
● User Experience Designer (UXD) develops a deep understanding of the target users’ (persona & use
cases)
o Interaction Design: tasks, navigation, and flow – produces wireframes (should be FTE)
o Information Architect: organization of data from user’s perspective (tree tests, card sort)
o Visual: produces mockups – precise layout, colors, fonts, emotional connection (prefer FTE, can
be contract)
● Usability Testing (may be outsourced, but PM & UX needs to be present)
o Create and iterate working prototypes (wireframe and high-fidelity prototypes)
o Recruit test subjects, administers tests, evaluate results, recommend modifications
● Product Marketing Manager (PMM)
o Tell the world about the product (positioning, pricing, messaging)
o External-facing product launch
o Sales and marketing tools
o Marketing campaigns and influencer marketing programs
Page 5 of 27

o Sometimes does competitive research
● Project Manager
o Manages release trains
o Includes coordination of engineering, site operations, customer service, and product management
o Should have a strong sense of urgency, be data driven, drive for clarity early and often, frame and
facilitate decisions
● Staffing ratios (only ballparks, varies widely)
o 1 PM for every 5 to 10 Engineers
o 1 UXD for every 2 PMs, 1 visual designer for every 4 UXDs
The Role of Product Management
The role of Product Management is wide-ranging and varies from company to company, industry to industry, and
depends on the needs and maturity of the organization. There is no “one size fits all” definition. However, there
are a number great frameworks that you can use as you build out the job descriptions for your organization.
Some of the best early work came for Pragmatic Marketing and their “Pragmatic Marketing Framework.” At a
high level, the framework identifies and defines the primary responsibilities of Product Owners, Product
Marketers, and Technical Product Managers. With this tool from Pragmatic Marketing, you can click on any box in
the framework and get a quick overview of the topic (see red boxes below).
Others have grouped some of these areas of responsibility into specific roles. See below for a possible grouping of
responsibilities for a Director of Product Strategy, Product Marketing Manager, and Technical Product Manager
Page 6 of 27

roles. Depending on the breadth of your product and size of your team, you may have one or more people
handling these responsibilities.
Mapping to some of the boxes above, Marty Cagan describes key questions for PMs to answer with respect to
product opportunities. Below we’ll summarize some of the documents used to answer these questions.1
1. Exactly what problem will this solve? (value proposition)
2. For whom do we solve that problem? (target market)
3. How big is the opportunity? (market size)
4. How will we measure success? (metrics/revenue strategy)
5. What alternatives are out there now? (competitive landscape)
6. Why are we best suited to pursue this? (our differentiators)
7. Why now? (market window)
8. How will we get this product to market? (go-to-market strategy)
9. What factors are critical to success? (solution requirements)
10. Given the above, what’s the recommendation? (go or no-go)
1
Marty Cagan (2008-06-04). Inspired: How To Create Products Customers Love. SVPG Press.
Page 7 of 27

Characteristics of Great Project and Product Managers
Marty Cagan provides a list of 7 key characteristics of great Project Managers .2
1. Sense of urgency. Just by walking into the room you instantly convey a sense of urgency. Pre-meeting
banter was maybe 60 seconds, and then it was down to business.
2. Framers. There are so many reasons for aimless, unconstructive meetings, but one of the biggest culprits
is that it’s not always clear to the participants exactly what the purpose of the meeting is, what problem is
to be solved, and what the specific issues or obstacles are. Great project managers understand how to
clearly and concisely identify and frame problems and run constructive meetings.
3. Clear thinking. The project manager needs to isolate the separate issues, and untangle the emotion and
baggage to expose the underlying problem and get everyone focused on pursuing the solution.
4. Data driven. Great project managers understand the key role that data plays in informing them about
precisely where they are and where they need to go. They are constantly looking to improve the product
development process and the result, and they know this begins with measurement. It is all too easy to just
shoot from the hip—especially in time-sensitive situations—so it’s essential for the project manager to
insist on the data to make sure the decisions are
5. Decisiveness. The project manager also needs to know when it is appropriate to collect data and
recommendations from the team, and when to escalate issues to senior management.
6. Judgment. Much of the above hinges on good judgment—knowing when to push, when to escalate, when
to get more information, and when to take someone aside and have a little private chat.
7. Attitude. Finally, there are always hundreds of very valid reasons why a product isn’t ready to ship—not
enough resources, not enough time, not enough money, etc. The job of the project manager is to get over
each and every one of these obstacles. At their core, great project managers are great problem solvers.
Dan Oslen provides a list of 10 best practices of successful Product Managers .3
1. Have a point of view but stay open-minded. You constantly have to make decisions under conditions of
uncertainty. Therefore, it's important to have a point of view and be decisive. At the same time, you
should identify how to test the areas of greatest uncertainty and risk. As you test, you should avoid
anchoring on your initial point of view and instead be objective and evidence-based. By listening with an
open mind, you will gain the most learning, which you should use to revise and improve your thinking.
2. Articulate your hypotheses. An interesting way to think of a product is to view it as the collection of all
the hypotheses that led to it becoming what it is. You should try to be as explicit as possible about the
hypotheses you are making. Writing down your hypotheses is incredibly helpful. Your teammates should
do the same, and you should make your team's hypotheses transparent. By posting your hypotheses
where everyone on the team can review them and by openly discussing them, they will only get better.
3. Prioritize ruthlessly. There are many ideas contending for resources when you are creating a product, and
tradeoffs are unavoidable. Being vague about your priorities usually leads to inefficiency and indecision.
Rank order your backlog and all other to-do lists. Clearly identifying what is most important helps you
spend your valuable resources and time wisely.
4. Keep your scope small but focused. Related to prioritization is the idea of deliberately keeping your scope
small. Smaller batch sizes encourage focus and are completed more quickly, enabling faster feedback
from customers. This doesn't mean that you should avoid tackling large tasks altogether— just that you
should try to split them up into smaller items to reduce risk and iterate more quickly.
2
Cagan, Marty (2008-06-04). Inspired: How To Create Products Customers Love. SVPG Press.
3
Olsen, Dan (2015-05-27). The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer
Feedback Wiley.
Page 9 of 27

5. Talk to customers. Your customers are the judges of product-market fit; they help you obtain the learning
that you need to achieve it. The sooner and more frequently you talk with customers, the better. It's
worth investing the effort to establish systems that make your user testing easier to schedule and
conduct, so that you talk to more users over time. Don't allow too much time to pass since your last user
test; customers will always surprise you with unexpected learning.
6. Test before you build. Many teams rush to build their product without testing any of their hypotheses.
But building before you've validated product-market fit will almost certainly waste resources. It is faster
and less costly to iterate with design deliverables than with an actual product. Plus, once a team builds a
product, they naturally grow attached to it, which can cause them to be less open-minded and less willing
to make major changes.
7. Avoid a local maximum. A local maximum means you have achieved the best results possible within the
range of options you have considered, but that better alternatives— that you haven't considered— exist
outside of those options. At this point, you need to take a fresh perspective to make further progress.
Shift your current thinking to a higher level and use divergent thinking to come up with new ideas worth
exploring.
8. Try out promising tools and techniques. Team members often employ tools and techniques with which
they have prior experience. Some product teams can be somewhat insular in this area, sticking to what
they know instead of seeking out potentially better solutions. In contrast, many product teams proactively
investigate new tools and techniques once enough people deem them better than the status quo. You
don't want to constantly change based on the latest fad, but it's valuable to compare notes with others
and stay relatively current on this front. You should give promising new ideas a try when they could
significantly improve how your team accomplishes its work.
9. Ensure your team has the right skills. Creating a successful product requires a wide range of skills. For
software products, the list of skills includes product management, user research, interaction design,
visual design, copywriting, Agile development, front-end coding, back-end coding, QA, DevOps, and
analytics. Different product teams will possess different levels of each important skill. You should assess
where your team is strong and where it is weak. Identify which skill improvements will make the biggest
difference in your situation and try to augment your team accordingly (e.g., through additional hires,
contractors, advisors, or training).
10. Cultivate your team's collaboration. Building products is a team sport. A product team creating a new
feature is like a basketball team scoring a basket. The product manager drives the ball down the court by
writing user stories and prioritizing the backlog. The product manager passes the ball to the interaction
designer, who designs the flows and wireframes and then passes the ball to the visual designer. The visual
designer creates the look and feel with high-fidelity mockups and passes the ball to the developer. The
developer, who implements the product based on the user stories and mockups, shoots the ball and
scores the basket. Strong skills alone don't make a great product team. Team members must each
understand their role, the other roles on the team, and how the team works together to achieve its
goals. You should take an occasional break from working to discuss how you work as a team and how you
can do so better (for example sprint and quarterly planning retrospectives). It's fun being on a team that
works well together, and strong collaboration increases your chances of building a Successful product.
Marty Cagan summarizes some key insights for PMs :4
1. The job of the product manager is to discover a product that is valuable, usable, and feasible.
2. Product discovery is a collaboration between the product manager, interaction designer, and software
architect.
4
Cagan, Marty (2008-06-04). Inspired: How To Create Products Customers Love. SVPG Press.
Page 10 of 27

3. Engineering is important and difficult, but user experience design is even more important, and usually
more difficult.
4. Engineers are typically poor at user experience design—engineers think in terms of implementation
models, but users think in terms of conceptual models.
5. User experience design means both interaction design and visual design (and for hardware-based
devices, industrial design).
6. Functionality (product requirements) and user experience design are inherently intertwined.
7. Product ideas must be tested—early and often—on actual target users in order to come up with a
product that is valuable and usable.
8. We need a high-fidelity prototype so we can quickly, easily, and frequently test our ideas on real users
using a realistic user experience.
9. The job of the product manager is to identify the minimal possible product that meets the
objectives—valuable, usable and feasible—minimizing time to market and user complexity.
10. Once this minimal successful product has been discovered and validated, it is not something that can be
piecemealed and expect the same results.
Problem Space and Solution Space
Customers don’t buy products and technologies, they buy experiences and outcomes. To build products that
succeed in the market, you provide a solution to a problem for a specific targeted customer.
The process starts with characterizing your target customers, then progressing through unmet needs (problems),
matching a value proposition to the unmet need (product-market fit), defining a feature set, and creating a user
experience with the given feature set that resonates, and ideally emotionally connects with, the customer. It's a5
6 step process:
1. Determine your target customers
2. Identify underserved customer needs
3. Define your value proposition
5
Feedback. Wiley.
Page 11 of 27

4. Specify your minimum viable product (MVP) feature set
5. Create your MVP prototype
6. Test your MVP with customers
Chapter 11 of The Lean Playbook has a detailed case study of a new product concept and testing (steps 1 through
6 above) which is an excellent resource.
Market segmentation can be done on a number of dimensions. You should select the dimensions that distinguish
the needs and characteristics of a group of customers as distinct from other segments.
● Demographic: age, gender, income, education, company size, industry, functional role, etc.
● Psychographic: attitudes, values, opinions, interests, emotion (fear, greed, lust, etc.)
● Behavioral: activity levels and patterns
● Needs-based: specific function and/or business benefit
As humans have a hierarchy of needs (see Maslow), customers have a hierarchy of needs. As PMs, we need to
recognize that we need to satisfy the lower level needs before customers will respond to higher level elements of
our offerings .6
6
Feedback. Wiley.
Page 12 of 27

When we build a MVP, we need to ensure it covers the spectrum of elements likely to ensure customer
engagement and satisfaction
Customer Personas
Personas are used to describe different target customers so that all stakeholders in the product development
team have a common understanding. Ideally they should be derived from ethnographic research with existing
and prospective customers in their work environment. Good personas convey the relevant demographic,
psychographic, behavioral, and needs-based attributes of your target customer. Personas should fit on a single
page and provide a snapshot of the customer archetype that's quick to digest. Below is an example from the Lean
Product Playbook.7
7
Feedback. Wiley.
Page 13 of 27

User Stories
Customer needs are described as “user stories.” A typical user story is written in the following format:
As a <type of user/persona>, I want to <do something>, so that I can <achieve a desired benefit or
business objective>
Here's an example of a user story that follows this template:
As a salesperson, I want to enter a prospective customer’s profile information and status in my CRM, so
that I can track the prospect through to a successful sale.
Bill Wake created a set of guidelines for writing good user stories; to make them easier to remember, he uses the
acronym INVEST :8
● Independent: A good story should be independent of other stories. Stories shouldn't overlap in concept
and should be implementable in any order.
● Negotiable: A good story isn't an explicit contract for features. The details for how a story's benefit will be
delivered should be open to discussion.
● Valuable: A good story needs to be valuable to the customer.
● Estimable: A good story is one whose scope can be reasonably estimated.
● Small: Good stories tend to be small in scope. Larger stories will have greater uncertainty, so you should
break them down.
● Testable: A good story provides enough information to make it clear how to test that the story is “done”
(called acceptance criteria).
Product Documentation
The 280 Group summarizes typical documentation that is created and managed by the product management
organization in conjunction with marketing.
8
http://guide.agilealliance.org/guide/invest.html
Page 15 of 27

The Business Model Canvas is a template for developing new or documenting existing business models. It visually
represents elements describing a product's value proposition, infrastructure, customers, and finances. The
Business Model Canvas was initially proposed by Alexander Osterwalder . Below you can see a sample business9
model canvas in the process of being developed10
Agile Product Development
Much has been written about Agile Product development. Great resources include:
● The Lean Startup by Eric Ries
● Getting Real by 37 Signals
● Running Lean by Ash Maurya
● Agile Product Management with Scrum by Roman Pichler
● Agile Software Development with Scrum by Ken Schwaber
9
https://en.wikipedia.org/wiki/Business_Model_Canvas
10
Steve Mullen, http://blog.bridgeapp.me/introduction-to-lean-canvas/
Page 16 of 27

If you want a quick, effective summary of Agile product development, please watch this video by Henrik Kniberg11
of Spotify and Lego. In 15 minutes you’ll get a very clear and easy to digest understanding of the tradeoffs
organizations need to make. There are several key takeaways that all stakeholders should understand. This is
without a doubt the best short video I’ve seen describing the agile development process in a way that anyone can
understand.
Consider sharing this across your company so everyone has a greater understanding of the processes that Agile
teams go through designing and building great products. Below is a summary of the key points made in this video
along with the timestamp corresponding to the point.
1. Product Owner (starting at 0:08 mins): Product vision, why we’re building, what problem it's going to
solve, and for whom. Stakeholder needs described as “user stories.”
2. Agile Teams (starting at 0:50 mins): Small, cross functional, self directed, co-located teams.
3. Stakeholders (starting at 1:40 mins): Product Managers (PM) have lots of stakeholders that they are
continually balancing and rebalance the needs of: existing customers, prospective customers,
professional services, marketing, business partners, etc.
4. Overload (starting at 1:55 mins): creates de-motivation and lowers output & quality – this is a state
that many companies are at today
5. Role of Product Owner (PMs, 2:30 min) is to manage workload to actual capacity (not the capacity we
wish we had...)
6. Backlog (3:20) – when demand exceeds capacity backlog continues to grow, Product Owners need to
say “NO” or backlog continues to build out of control
11
Henrik Kniberg from Lego, https://www.youtube.com/watch?v=502ILHjX9EE
Page 17 of 27

7. Prioritization (4:20) – value and size analysis in conjunction with stakeholders determines what we do
and in what order, not everything can be of equal importance
8. Guessing game (5:15) – value and size are guessing games, imprecise by nature at the early stages
(how big is the market for product X, how strategically important is product Y, how long will it take to
internationalize all products and platforms, etc.
9. Refining the estimates (5:50) – it’s an iterative process, feedback loop and bite-sized chunks are
required, refine timelines as you progress
10. Feedback loop on delivery schedules (6:10) “trying to get it all right at the beginning is pretty dumb,
because that’s when we know the least”
11. Backlog grooming (6:45) – iterative refining done by the PM in collaboration with stakeholders (new
market data on size/value, new engineering insight on the scope and amount of effort, etc.)
12. Tradeoffs (7:45) – managing risks: business understanding, technical execution, cost and schedule risk
13. Knowledge acquisition (8:12): User Experience (UX) design and experimentation early to build
knowledge and reduce risk
14. Customer value over time (8:30) – as uncertainty is reduced through knowledge acquisition, teams
can focus execution building customer value, but we can’t skip the knowledge acquisition stage
15. Short term vs. long term choices (9:18) – balancing firefighting vs. fire prevention (today many
companies are doing a significant amount of firefighting)
16. Balancing across 3 goals (9:40): build the right product (PM), build the product right (PE), build it fast
(Sales) – tension between all three goals, while balancing new product development with existing
product enhancements (10:43)
17. Managing expectations (11:30) – forecasting is not exact for all the points above
18. Cone of Uncertainty (12:25) – fixed scope/variable timeline vs. fixed time/variable scope forecasting,
most companies should be doing fixed time/variable scope
a. The implication is that we can’t predict with absolute certainty every line item that can be
delivered in a fixed timeline, there are confidence ranges
b. (14:08) use real data, be honest, no lying. “if your organization doesn’t like truth and
honesty, they won’t like Agile.”
c. PM should begin presenting roadmaps with confidence ranges – most important items
will have tighter timeline confidence levels, lower priority items will have wider timeline
estimates
19. Accumulating technical debt (14:20) – if you’re not investing in architecture, automated testing and
deployment, refactoring, productivity tools, etc. then productivity will decline over time
20. Synchronizing multiple product teams (14:45) – dependencies need to be managed across tracks so
some individual product timelines may be slowed for the greater good of the portfolio
Succeeding with Agile from The Lean Playbook12
● Cross-Functional Collaboration.
○ Agile depends on strong cross-functional collaboration. There should be free and frequent
communication among product managers, designers, developers, QA, and any other team
members, who should speak daily. It's essential to avoid creating silos where each function throws
their work product “over the wall” to the next function in the workflow. A certain amount of
face-to-face real-time communication is critical to maximize shared understanding and team
velocity. High-performing teams also employ communication tools such as chat, a
12
Feedback. Wiley.
Page 18 of 27

development-tracking tool (e.g., JIRA Agile), and knowledge collaboration tools (e.g., a wiki or
Google Docs) to work together effectively.
○ Every function should be involved throughout the process, though it's natural for a particular
function to be more involved than others and take the lead during a certain phase. In a nutshell:
product managers write the user stories, then designers create artifacts, then developers code,
and then testers test. But product development is a team sport. Developers and testers should
have some involvement early in the development process so that they understand the rationale
behind product decisions, user stories, and UX designs. The team should encourage them to ask
questions and make contributions at all stages. Similarly, product managers and designers should
be in the loop during development and testing, especially since unforeseen questions or issues
often crop up then.
○ Effective collaboration helps the team achieve shared vision and avoid misunderstandings, and
allows the team to move faster. Each team member makes numerous decisions about the product
every day. If the team has shared vision and understands the objectives and rationale, members
are more likely to independently make decisions that support that vision.
● Ruthless Prioritization
○ You should maintain an up-to-date, prioritized backlog. It is important to be clear about the next
set of user stories you plan to implement when resources permit. This allows you to act quickly.
High-tech product teams usually operate in a dynamic environment where requirements and
priorities change quickly. It's not enough to identify items as high, medium, or low priority. If a
backlog has 15 high priority items, it won't be clear which of those items a developer should start
on first when her time frees up. Priority levels are useful but not sufficient; you also need to rank
order your backlog items within each level. I am a fan of ruthless prioritization (which, for the
record, is the opposite of wishy-washy prioritization). Having your backlog rank ordered makes it
clear which item should be done next. It also makes it much easier to determine where new
requirements belong in the backlog when they come up.
○ The trick is to be both rigid and flexible when it comes to prioritizing your backlog. You must be
clear on your rank order priorities at any point in time; but you must also be able to quickly
incorporate new or changing requirements. I use the analogy of water and ice. Most of the time,
your backlog is like ice; the rank order is frozen and fixed. But when new requirements come in
or priorities change, you briefly melt the ice into liquid water so you can rearrange things. Once
you're done reordering your backlog, you freeze it again. Following this approach means that your
backlog will be up to date whenever anyone looks at it. A developer can reliably pull the item at
the top of the stack and start working on it without having to confer with anyone.
● Adequately Define Your Product for Developers
○ It's important to provide your developers with the information they need to build the desired
product. A set of well-written user stories with accompanying wireframes or mockups usually
does a good job of that. If the team already has a style guide in place and isn't introducing any
new major UX components, wireframes are usually adequate. If, however, visual design details
need to be conveyed, then mockups should be used. For features that are purely back-end with
no UX component, wireframes or mockups aren't required. The team should ensure that it isn't
just the happy path— that is, the expected path of user behavior— that they're defining. Rather,
they need to think through the different conditions and states that could apply. There is a
balancing act here. On one hand, you want to provide enough definition that developers can start
building with confidence that you didn't fail to think through an important aspect. On the other
hand, you don't want to experience analysis paralysis where you spend so much time fretting over
every detail that implementation gets significantly delayed.
● Stay Ahead of Developers
Page 19 of 27

○ Many teams have struggled with integrating UX design into their Agile development process. The
guidelines for Scrum don't explicitly deal with how best to handle this. It doesn't work well if the
designer is creating wireframes for a user story at the same time that the developer is trying to
code it.
○ In order for Agile teams to achieve their highest velocity, developers need to be able to hit the
ground running when they start on a new user story— which means that the team must finalize
the user stories and design artifacts beforehand. Because you want to achieve a steady flow of
work, designers need to be at least one or two sprints ahead of the current sprint. Of course, the
designers need solid user stories on which to base their designs— so product managers need to
be working one or two sprints ahead of the designers.
○ The goal is to make sure that you never starve developers for work and always have at least one
sprint's worth of fully groomed backlog ready to go. This requires some balance, because you
don't want to specify too many sprints in advance, as things could change. And while I've
described the situation in terms of Scrum, it also applies to kanban. Based on the designers' cycle
time, PM should ensure there are enough cards in the “ready for design” queue. Likewise, based
on the developer's cycle time, designers should ensure there are enough cards in the “ready for
development” queue. Neither the product managers nor the designers should be doing their work
in a vacuum. The team needs to carve out a certain amount of time in the current sprint to review
and discuss user stories and designs for future sprints.
● Break Stories Down
○ Being Agile requires working in small chunks. I mentioned earlier that user stories should not be
allowed to exceed some reasonable maximum size (i.e., number of story points). Beyond that, you
should strive to break stories down into the smallest size possible. If you have a five-point story,
try to find a way to break it into a three-point story and a two-point story. Better yet, try to break
it into a couple of two-point stories and a one-point story. This may seem difficult at first, but like
most things, you will get better with practice.
○ If you're unable to break the story down any further, then the developers should try to break
down the tasks required to implement the story. If they are having trouble doing that, start by
enumerating the steps they plan to take to get the work done. Smaller scope stories and tasks
result in smaller estimation errors. Dividing user stories into smaller pieces usually requires that
you think about them in more detail, which also reduces uncertainty and risk. You may realize
when you break a story down that some elements of it are more important than others, which
can help you refine your prioritization. The same advice applies for kanban, even if you're not
using story points. Try to break each larger scope card into several smaller scope cards.
● Test-Driven Development
○ Many Agile product teams practice test-driven development, a technique where developers write
automated tests before they write code. Before coding a desired new functionality or
improvement, the developer thinks about how to test it and writes a new test case. The test case
should fail when the developer first runs it— because the code has not been changed yet. If the
initial test doesn't fail, it indicates that the developer did not write the test correctly. The
developer writes code until she thinks she is done and then runs the test again. If the test doesn't
pass, the developer keeps working until the test passes.
○ After a successful test, the developer will often refactor the code to improve its structure,
readability, and maintainability without altering its behavior (while ensuring it still passes the
test).
○ Test-driven development, also called TDD, has several advantages. First, it usually leads to higher
test coverage, which is the percentage of your product's functionality that is covered by
automated tests. As a result, you'll tend to miss fewer regression bugs— and enhance the team's
Page 20 of 27

confidence when they modify existing code (since automated testing lets them easily verify that
they didn't break anything). TDD does require some overhead to maintain tests as the product
changes over time. But if a team wants to scale their automated regression testing as the product
grows, then they need to write new test cases as new functionality is developed— whether they
decide to practice TDD or not.
Analytics, Customer Engagement, & Monetization
Once you’ve built a great product, it's important to work with marketing to monetize your offerings and improve
your product. For B2C and B2B2C products, consider the various stages of the customer engagement lifecycle.
Dave McClure of 500 Startups has a good presentation on this here. He summarizes the 5 steps with the pirate
phrase “AARRR!”
● Acquisition: users come to the site from various channels
● Activation: users enjoy 1st visit: "happy" user experience
● Retention: users come back, visit site multiple times
● Referral: users like product enough to refer others
● Revenue: users conduct some monetization behavior
There is a great BrightTALK video presentation entitled “How to Optimize your Product Using Analytics” that walks
you through how to use analytics to determine when, where, and how to focus your product efforts on the
various stages of customer engagement and monetization. The slide deck used in the presentation is here. I
strongly encourage you to watch the video as the discussion gives great context to the slides. Key components:
Page 21 of 27

Another great resource is an article conversion rate optimization (CRO) and 27 techniques to improve conversion
rate. I won’t list all 27, but here are few examples. Each technique has a link to a detailed discussion:
● Installing a tag manager (to help you activate and deactivate tags without having to speak with your IT
department each time).
● Capturing easy-to-interpret click-maps (to see exactly where visitors clicked—even if it wasn’t on a link).
● Using session-recording tools (to see videos of visitors’ screens and more).
● Using form-analytics software (to identify which of your form fields are causing trouble).
● Using live chat (to let your visitors tell you what’s wrong with your pages).
● Using co-browsing (so your visitors can share their screens with you).
● Using exit survey tools (to ask your visitors why they didn’t take action).
● Using on-page survey tools (to ask questions at exactly the right moment).
● Talking to a “VOC Aggregator” (perhaps the fastest way to understand users).
● Encouraging your visitors to phone you (so you can understand them better).
● Running user-tests (to see your pages’ shortcomings first-hand).
● Using pop-up surveys (to recruit participants for your user-tests).
● Using A/B-testing (to test different versions of your webpages to see which is the best).
● Bonus Technique: Conversion for low-traffic websites, (revealing which of the above techniques work best
when you don’t have many visitors.)
Pricing Strategies
Some organizations have the marketing team lead on pricing, others have the product team take the lead.
Regardless of who is leading the process, the product team needs to be intimately involved in pricing strategies
and execution. There are a number of good resources on pricing, especially for SaaS offerings. Thanks to Jan
Kotowski for these recommendations:
Page 23 of 27

● The Anatomy of SaaS Pricing Strategy by Price Intelligently/ProfitWell
● Zuora Practical Pricing Guide
● Pragmatic Pricing by Mark Stiving
Some highlights include (this section is still in development):
●
Overall Leadership and Organizational Development
Beyond Product Management specific best practices, there are a number of good resources for leadership and
team effectiveness. Some of the best and most relevant that I have found are from Laszlo Boch, SVP HR at Google
in his book Work Rules and Jim Collins of Stanford on Level 5 leadership in his book Good to Great. Finally, Google
has published something called re:Work which is a collection of practices, research, and ideas from Google and
others to help you put people first.
○ Best Practices for Managers (highlights from Google project Oxygen)
■ Be a good coach
■ Empower the team and do not micromanage
■ Express interest/concern for team members’ success and personal well-being
■ Be very productive/results-oriented
■ Be a good communicator – listen and share information
■ Help the team with career development
■ Have a clear vision/strategy for the team
■ Have important technical skills that help advise the team
○ Best Practices for Groups (highlights from Google project Aristotle). Characteristics of high
performing teams regardless of project type, age, experience, educational background, diversity
or other variables.
■ Psychological safety
■ Dependability
■ Structure and clarity
■ Meaning
■ Impact
○ Level 5 Leadership (from Good to Great). Good executive summary here.
■ Develop humility
■ Ask for help
■ Take responsibility
■ Develop discipline
■ Find the right people
■ Lead with passion
○ re:Work Resources
■ Goal Setting
■ Hiring
■ Innovation
■ Learning & Development
■ Managers
■ People Analytics
■ Teams
■ Unbiasing
Page 24 of 27

Final Guidelines and Recommendations
10 Best Practices for Creating Inspiring Products from Marty Cagan’s Inspired13
1. The role of product management. Too many product leaders spend their time on other activities,
especially product marketing and/or project management. These activities are not a substitute for true
product management.
2. The role of user experience. For most software products, the user experience is all-important. Devising a
good user experience requires that you collaborate closely with an interaction designer and an engineer
to come up with something that is valuable, usable, and feasible.
3. Opportunity assessments. These lightweight, to-the-point assessments replace the old “MRD” (market
requirements documents). Before you jump into the solution, know what problem you’re trying to solve,
who you’re trying to solve it for, and how you’ll know if you are successful.
4. Charter user program. It is shocking to me how many product teams think they can come up with great
products without talking to users and customers. If you only do this one thing, it will ensure that you do
several other things right, starting with direct and intense user interaction.
5. Product principles. The product principles help you identify and prioritize what you believe is important.
Product: low cost, high performance, flexible, comprehensive, simple, etc. Design: “well lit path,”
“progressive disclosure,” “contextual cues”
6. Personas. Another key technique for making the difficult choices required for an inspiring product is to
use personas as a way to focus your release and to understand the key behaviors and underlying
emotions of the target users.
7. Focus on discovery. The primary responsibility of the product manager is to discover a product that is
valuable, usable, and feasible. It makes no sense to proceed to building something until you have
evidence that you have discovered this product.
8. The use of prototypes. One of the most important product discovery techniques is to create a
high-fidelity prototype. We do this for several reasons: First, it forces you to think much deeper about the
solution; second, it enables you test your ideas out with real users; and third, it is the most useful way to
describe the product to be built to the rest of the product team.
9. Test prototype with target users. Once you have a prototype, you can find out which of your ideas works
and which do not. The techniques for this prototype testing are something that all product managers and
designers need to master. Knowing how to get feedback on product ideas is probably the single most
important skill for product managers.
10. Measure to improve. The successful product manager uses data to make important decisions, especially
when trying to improve an existing product. Improving a product is not about adding features that
customers request; it is about analyzing the product’s actual use, and then relentlessly driving the
product to improve the key metrics.
Top 10 Worry List from Marty Cagan’s Inspired. Below are some questions you should constantly be asking14
yourself and the entire product team.
1. Is my product compelling to our target customer?
2. Have we made this product as easy to use as humanly possible?
3. Will this product succeed against the competition? Not today’s competition, but the competition that will
be in the market when we ship?
4. Do I know customers who will really buy this product? Not the product I wish we were going to build,
13
14
Page 25 of 27

but what we’re really going to build?
5. Is my product truly differentiated? Can I explain the differentiation to a company executive in two
minutes? To a smart customer in one minute? To an industry analyst in 30 seconds?
6. Will the product actually work?
7. Is the product a whole product? How will customers actually think about and buy the product? Is it
consistent with how we plan to sell it?
8. Are the product’s strengths consistent with what’s important to our customers? Are we positioning
these strengths as aggressively as possible?
9. Is the product worth money? How much money? Why? Can customers get it cheaper elsewhere?
10. Do I understand what the rest of the product team thinks is good about the product? Is it consistent
with my own view?
Managing Up. In addition to leading the product team, are you thinking about how you support and interact15
with the executive leadership team.
1. Measure and plan for churn. Churn is the cost of the various drills, rework, and changes in plans that
cause the frustration. Constantly strive to reduce it. This starts by increasing awareness of churn, and
that begins with measuring it. Try to track how much of your week/month/quarter is spent on forward
progress. When you’re scheduling your projects, know that there will be a percentage of your time
devoted to responding to these changes and adjusting accordingly. It will help manage your stress level,
make your schedules more accurate, and help you identify issues you can try to improve.
2. Communication style and frequency. Just as product managers are not all the same, managers are not all
the same either. Some managers prefer to be kept apprised of every little detail on a continual basis.
Others don’t want you to bother them unless there’s an escalation or serious issue that needs your
manager’s help. Some prefer updates in writing with detailed supporting material, and others prefer a
quick chat in the hall. You need to determine the style that your manager prefers and do your best to
meet that need, even if it’s not your own preferred style.
3. Pre-meeting work. Most product companies have lots of meetings—too many. The more stakeholders
there are in your organization, the more you’ll be asked to have checkpoint and review meetings to keep
everyone on track and informed. There are many techniques for running good meetings, but the main
point here is to actually conduct the real meetings before your official meeting. This means going
individually to the key stakeholders prior to the actual meeting and giving them a preview of your points,
listening to their issues, and ensuring that they are already on board by the time the group meeting
happens. If you do this well, the group meeting should be quick with no surprises.
4. Recommendations, not issues. Most managers prefer to see your recommendations on how to solve
problems you encounter rather than just a statement of the problem. Ideally, depending on the size of the
problem, this means an analysis of several alternatives along with your recommendation and rationale.
5. Use your manager. Managers can often be a very useful tool that most employees underutilize. As an
example, suppose there’s a problem you’re working to solve, and you have an analysis and
recommendation, but some of the key influencers are not anxious to make the time available you need to
pre-brief them as described in the pre-meeting work above. Your manager can often get the access you
can’t.
6. Do your homework. One of the biggest mistakes product managers make is in not doing their homework.
Managers are usually smart and can quickly identify holes in thinking and in plans—that’s their job. The
best way for you to prepare for this is by doing your homework. You need to understand the issues
thoroughly and be prepared.
15
Marty Cagan (2008-06-04). Inspired: How To Create Products Customers Love. SVPG Press
Page 26 of 27

7. Short e-mails. Another common mistake is that product managers like to write long, detailed emails to
their managers, but then get frustrated when they’re not read or responded to. You need to realize that
your manager is probably getting hundreds of e-mails a day, and is looking for short, to-the-point
communications. The more senior the person you’re sending to, the shorter you’ll want the email to be.
Offer additional material, but don’t make the manager read more than a few lines.
8. Use data and facts, not opinions. When dealing with managers—especially senior managers—it’s
essential to remember that your job is to provide the data and facts. Jim Barksdale, the former CEO of
Netscape, had a great line when he was confronted with difficult decisions. He said, “If we’re going to
make this decision based on opinions, we’re going to use my opinion.”
9. Evangelize. A big part of a product manager’s job is to evangelize the product across the organization. If
you evangelize effectively, everything will become easier—especially working with other groups in the
company. If they know what you’re doing and are excited about what your product will do for the
company, they’ll be much more likely to find ways to help.
10. Low-maintenance employees. One of the secrets that nearly every manager thinks—but few will
admit—is that what they’re really looking for in an employee is someone who is low maintenance.
High-maintenance employees consume a disproportionate amount of the manager’s time and attention,
and while it’s your manager’s job to ensure that his team is productive, there is only so much time in the
day. And be thoughtful of how you use of your manager’s time.
Page 27 of 27

Product Management 101: Techniques for Success

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Product Management 101: Techniques for Success

Semelhante a Product Management 101: Techniques for Success (20)

Mais de Matterport

Mais de Matterport (8)

Último

Último (20)

Product Management 101: Techniques for Success