Product Management 101: Techniques for Success By Brian Kissel

Table of Contents Resources General Overview The Role of Product Management Characteristics of Great Product Managers Problem Space and Solution Space Customer Personas User Stories Product Documentation Agile Product Development Succeeding with Agile from The Lean Playbook 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. The following are additional resources that Dan recommends:

○ What Customers Want by Anthony Ulwick ○ UX for Lean Startups by Laura Klein ○ The Lean Startup by Eric Ries ○ Running Lean by Ash Maurya ○ Crossing the Chasm and Inside the Tornado by Geoffrey Moore ○ Inspired by Marty Cagan ○ The Inmates Are Running the Asylum by Alan Cooper ○ Don't Make Me Think and Rocket Surgery Made Easy by Steve Krug ○ The Non-Designer's Design Book by Robin Williams ○ The Elements of User Experience by Jesse James Garrett ○ Measuring the User Experience by Tom Tullis and Bill Albert ○ Designing for Emotion by Aaron Walter ○ Smart Choices by John Hammond, Ralph Keeney, and Howard Raiffa ○ Pretotype It by Alberto Savoia ○ Information Visualization by Colin Ware

● Henrik Kniberg: Agile Product Ownership in a Nutshell ● Geoffrey Moore: Crossing the Chasm, Dealing with Darwin

Page 1 of 23

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 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 (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 “job 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 mock-ups (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

Page 2 of 23

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 o PM, UX, Engineering, Marketing, Sales, PS, CS, Site Ops 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.

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 ● 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

Page 3 of 23

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

Tools and Technology – standardize where possible, based on the needs of the groups

● Feature/Bug tracking: Jira, VersionOne, Redmine, etc. ● Product Planning: 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 ● 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, etc.) o Website analytics (Omniture, WebTrends, Google, Totango, etc.) o A/B testing (Optimizely, Monetate, Maxymizer)

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 o Sometimes does competitive research

● Project Manager

Page 4 of 23

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

Page 5 of 23

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 above).

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 roles. Depending on the breadth of your product and size of your team, you may have one or more people handling these responsibilities.

Page 6 of 23

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 1

questions.

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 23

Characteristics of Great Product Managers Marty Cagan provides a list of 7 key characteristics of great PMs . 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 product 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

Not to be outdone, Dan Oslen provides a list of 10 best practices of successful PMs . 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.

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 8 of 23

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.

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. It's fun being on a team that works well together, and strong collaboration increases your chances of building a Successful product.

Page 9 of 23

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. 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

4 Cagan, Marty (2008-06-04). Inspired: How To Create Products Customers Love. SVPG Press.

Page 10 of 23

experience with the given feature set that resonates, and ideally emotionally connects with, the customer. It's a 5

6 step process:

1. Determine your target customers 2. Identify underserved customer needs 3. Define your value proposition 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

5 Olsen, Dan (2015-05-27). The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback. Wiley. 6 Olsen, Dan (2015-05-27). The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback. Wiley.

Page 11 of 23

When we build a MVP, we need to ensure it covers the spectrum of elements likely to ensure customer engagement and satisfaction

Page 12 of 23

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 Olsen, Dan (2015-05-27). The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback. Wiley.

Page 13 of 23

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 14 of 23

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 business 9

model canvas in the process of being developed 10

9 https://en.wikipedia.org/wiki/Business_Model_Canvas 10 Steve Mullen, http://blog.bridgeapp.me/introduction-to-lean-canvas/

Page 15 of 23

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

If you want a quick, effective summary of Agile product development, please watch this video by Henrik Kniberg 11

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.

11 Henrik Kniberg from Lego, https://www.youtube.com/watch?v=502ILHjX9EE

Page 16 of 23

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

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

Page 17 of 23

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 Playbook 12

● 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 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

12 Olsen, Dan (2015-05-27). The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback. Wiley.

Page 18 of 23

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 ○ 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

Page 19 of 23

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 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.

Page 20 of 23

Guidelines and Recommendations 10 Best Practices for Creating Inspiring Products from Marty Cagan’s Inspired 13

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 14

asking yourself and the entire product team.

1. Is my product compelling to our target customer?

13 Marty Cagan (2008-06-04). Inspired: How To Create Products Customers Love. SVPG Press. 14 Marty Cagan (2008-06-04). Inspired: How To Create Products Customers Love. SVPG Press.

Page 21 of 23

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, 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 15

interact 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

15 Marty Cagan (2008-06-04). Inspired: How To Create Products Customers Love. SVPG Press

Page 22 of 23

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.

7. Short e-mails. Another common mistake is that product managers like to write long, detailed e-mails 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 e-mail 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 23 of 23