8 Trends Shaping Modern Product Management

A brief post to list eight trends that are shaping modern product management. This is based on my personal observations. Your observations…

8 Trends Shaping Modern Product Management

A brief post to list eight trends that are shaping modern product management. This is based on my personal observations. Your observations may vary.

Rise of UX and “consumerification” of the enterprise. Even for B2B the UX bar is set extremely high. “Just winging it” is not an option. Gone are the days when a PM can do double duty as an interaction designer, UX Researcher, information architect, and visual designer. Design thinking is being mentioned hand-in-hand with DevOps, organizational design, service design, and Agile itself.
Multiple touch-points. You’re not just working on a desktop web browser. A typical product will have multiple touch-points including mobile, tablets, and even connected devices (“things”). Products integrate services from large and complex ecosystems. It’s a lot to process.
Lean Startup and LeanUX. A focus on validated learning vs. big batches based on unvalidated assumptions. Product development is cast as an incremental learning process vs. a feature delivery process. Authors like Jeff Gothelf and Josh Seiden (authors of Lean UX: Applying Lean Principles to Improve User Experience) stress a focus on “outcomes over features”. One of the most notable Lean Startup artifacts is the “MVP”. In its earliest incantation this was actually meant to be a Minimally Viable Product **Experiment. **It’s not truly viable to sell or market, but rather designed to elicit learnings and guide what will eventually be viable to users.
**Increased customer/user community management demands. **Customers have countless touch-points through which to interact with your company. Consider the rise of companies like Intercom and others. While incredibly valuable, this can add a significant burden for already overextended product managers. An outward facing role is a necessity. But can a single person juggle that with internal facing demands?
**Continuous delivery. **Teams are delivering high quality code more quickly and in smaller batches. Heavy release train management is less common. This is a double-edged sword. On one hand it limits batch size (and onerous release planning) which is almost always positive. On the other hand it increases demands on teams for rapid tactical product ownership and coordination.
**Kanban and Post-Scrum Agile. **To support continuous delivery, teams are adopting new approaches (e.g. Kanban Method) that challenge the traditional cadences of Scrum which in turn challenge traditional PO roles within Scrum. Accepting stories becomes near continuous. Grooming is ad-hoc based on demand. This presents a scheduling nightmares for the busy PM and further necessities a level of dedication and availability to the team.
**Availability of data (both qualitative and quantitative) and ease of instrumentation. **Teams are swimming in data and new tools allow easy feature instrumentation. A Google PM ad lists the following qualification: “demonstrated ability to dive into quantitative and qualitative data and derive data-driven solutions.” Basic statistics, experiment design, ethnography, and general research methodologies are now essential product manager skills. It is becoming increasingly clear that to some extent we’re all guessing (sometimes educated guesses, but guesses nonetheless). The data side presents immense opportunities to build quickly, measure, and learn.
**Expanded definitions of Agility. **There is a new focus on “whole organization” Agility vs. traditional Business/Team silos. Siloed teams require a “glue” role — aka Product Manager — to manage disparate stakeholders. Increasingly these barriers are falling to the wayside. In their place are autonomous business units with all the resources necessary for ideation, delivery, marketing, and revenue generation. The distance from the team to other stakeholders is shorter.

Below is an amazing infographic by Roman Pichler available here. In pink I’ve indicated where the trends above impact traditional product manager responsibilities. UX has firm influence in the “User Experience and Product Backlog” sector. Lean Startup and LeanUX overlap “Strategy and Market Research”. Continuous Delivery impacts roadmap creation and “key events” (aka release planning / product lifecycle management). And data impacts multiple areas.

So what does this all mean for product managers? I’ll save that for another post. Please comment if you have anything to add.

The System Thinking Change Agent Survival Guide

For my first post on Medium I wanted to cut straight to a topic that is rather personal. It’s personal in the sense that I represent the…

The System Thinking Change Agent Survival Guide

For my first post on Medium I wanted to cut straight to a topic that is rather personal. It’s personal in the sense that I represent the personality type I’m about to describe. It’s something I’ve come to peace with over the years but the road has not been easy.

For the purpose of this post I’ll call the archetype **STCA (**Systems Thinking Change Agent). It’s weird, I know, but it’ll have to do and I’ll explain more below. I was tempted to call it just a Change Agent —the post definitely has a change agent angle — but that wouldn’t fully describe the personality.

For some perspective, when I was in 2nd grade I played the part of the “Eternal Question” in our blockbuster play Vernacular Island. My costume was a big question mark taped to a headband.

The Eternal Question

The Traits

So what does a STCA look like? How would you pick him/her out of a crowd? If you’re a STCA you …

are intense, reasonably intelligent, and move and think quickly
are a systems thinker. Systems thinking “concerns an understanding of a system by examining the linkages and interactions between the elements that compose the entirety of the system”. For you, thinking this way is unavoidable
care deeply about people and don’t like to see them frustrated, thwarted, tense, stressed, or manipulated. This impacts you on a visceral level, you internalize it, and you take on these struggles as your own
have a growth mindset, and assume a growth mindset in others. A growth mindset is “the belief that qualities can change and that we can develop our intelligence and abilities.” You assume (often incorrectly) that people are open to change, receptive to constructive feedback, and able to follow your logical reasoning and change direction as quickly as you
are passionate about the truth and discovering root cause (and various techniques to do this). Cognitive dissonance is unsettling and motivates you
are trusting in the basic good in people (you have faith that people can “come around” eventually)
are social and vocal and feel comfortable voicing what you are feeling/thinking. You’re an advocate
a natural problem solver with a lot of persistence, but lacking a certain level of political savviness

Allergy Test

A good test for STCA-ism is whether you have a allergic reaction to any of the following statements. Say them aloud, and see if you get hives or your heart rate increases:

“Sometimes things are just political” or “Just because…”
“You’re over-thinking this”
“I’m not sure we can trust this information with those people …”
(A fellow coworker) “I gave up on trying to change that a long time ago”

Did any of these quotes trigger anything? If so, maybe you have some shades of STCA-ism.

The Pitfalls

As a STCA, sooner or later you’ll stumble into the following pitfalls. I know because at some point or another I’ve been there. With the best of intentions you go with your gut, lay it on the line, and things don’t end up working for whatever reason.

**You’ll mistake people listening to you for people supporting you. **Most people are eager to hear new ideas and fresh perspectives… to a point. They might even thank you for “challenging [their] thinking”. But this doesn’t necessarily equal support or a willingness to act on that feedback. At a certain point it becomes “too much” and the mood shifts from openness to rejection and annoyance. Solution: Don’t assume listening correlates with support. And don’t assume — especially with email — that the lack of response equates to tacit understanding.

You’ll quickly find allies but you’ll overestimate the number of people who really care. Being vocal tends to attract likeminded people. Assuming that this sample is representative (at least in terms of how much they care) can be a costly mistake. Odds are that you’ve probably made contact with the minority of people who both notice and care enough about the issue. That doesn’t mean there aren’t others sympathetic to your effort (there most certainly are) but you can’t expect people to take too many risks. Solution: Don’t count on reinforcements until after you’ve reached the tipping point.

You’ll assume others care as much as you do (and care about the same things). “Care” is a loaded word. We’re conditioned to equate care with virtue, and may even consider ourselves virtuous for caring about or advocating for something. But people are wired in different ways. I know plenty of people who care deeply about certain aspects of work (e.g. the money, the facilities, the brand of coffee) but could care less about things like customers, culture, priorities, or ways of working. This doesn’t mean they wont express some passing interest in those topics, but rather that when the chips are down they’ll pass. Solution: Don’t use your level of concern or values as the benchmark. If anything, underestimate interest and intent.

You’ll misunderstand “how things actually work”. Like most systems, the deeper story for an organization is rarely evident on first blush, and certainly defies value statement platitudes and the recruiting sales pitch. It can’t be fully understood by looking at an org chart, and can be difficult to triangulate by talking to a handful of people. Who really calls the shots? What do people really care about? What happens to people who question the status quo? What is the “real” culture? **Solution: **Use your systems thinking hat! Make a concerted effort to map organizational dynamics. Carefully observe to understand the culture as expressed through actions. Be honest about what the status quo optimizes for and whether that is conducive to your proposed change.

You’ll think you’re the only one to notice the problem. It’s easy to assume that the problem is obscured and if people could SEE the problem they’d be open to fixing the problem. More likely, the problem is clear and known to a more people than you’d think. Some are playing the long game (see below). Some people don’t really care enough to cause a fuss. Some people have alternative interpretations and/or political motivations. Don’t talk yourself into the “problem evangelist” role. It’s a losing game. Solution: Test for how other people perceive the problem. Test for their current tactics and approach. Then find a way to test whether you can enlist support.

You’ll misunderstand why other people are not speaking out. Your fellow change agents all may have similar motivations, but you may find yourself being the most vocal representative. Why? They know something you don’t know or sense something you don’t sense. It’s important to understand and respect where they’re coming from. They may have tried getting into the ring at some earlier point and were knocked out. Accept that this puts you in a somewhat precarious “kill the messenger” position. Solution: Empathy and understanding. Seek to understand their resistance to being more vocal. Try to distribute the pressure for change among more people.

**Your motives will be misunderstood. **Push beyond a certain point and you’ll be easily branded as a “too negative” or “only talking about problems”. Don’t be so quick to discount this feedback as you’d likely do the same thing if the tables were turned. Recognize that you’ve likely amped up the intensity level as you try to push through resistance. You’re responding to resistance, they’re responding to intensity, and so it goes. **Solution: **Do whatever possible to avoid the downward spiral. Be especially descriptive about your motives (building trust, continuous improvement, positive change, etc.)

You’ll get caught playing the short game. Some people play the short game and go down in a blaze of glory (or with luck into a lightning victory). Others methodically play the long game, chipping away at structures, forming alliances, and forging change. If you play the short game then you have to understand the risks involved (an organism attacked rejects threats). This may be fine — life is too short to continue doing something that brings you down — but realize what you’re getting into. And don’t judge the “long gamers”. It’s an individual decision. Solution: Decide in advance whether you are willing to play the price for playing the short game. It’s a gamble. To quote Kenny Rogers:

You’ve got to know when to hold ‘em
Know when to fold ‘em
Know when to walk away
Know when to run

**You’ll overestimate the power of bottom-up change. **Bottom-up change is extremely difficult. At a certain point you hit the glass ceiling of established systems and structures. After any period of time those structures become rigid, self-perpetuating, and extremely difficult to “nudge”. Even Herculean individual efforts fail here. So be prepared. Consider the long game. **Solution: **Be honest with yourself about the feasibility of bottom-up change. Work tirelessly to influence someone with the power to enact far reaching change. Consider the long-game.

You’ll assume that people have the same change vision. Even in cultures that stress continuous improvement it is common for individuals and groups to jockey for ownership of change efforts. On the surface you may see openness to change. But if you peel away the layers you’ll find competing visions for change. Realize that people may agree that change is required, but be split on tactics. In my experience this is the norm. The problem typically isn’t the problem, but rather the competition for who solves it (and how). **Solution: **Map the various efforts to address the problem. Understand who shares your perspective. Understand where there is tension.

Now What?

I’m the last person to suggest that you become someone who you aren’t. The first thing to realize is that your experience will be highly org/culture specific. This is absolute key to understand. For most STCAs there is no reigning us in. It’s an ingrained mindset. Finding the right culture and environment is key.

Much of what you read online about change is written from the perspective of consultants and managers. This is top-down and outside-in change and not bottom-up change. But resistance is resistance, and it will always be a factor. The reality is that from this vantage point you’ll do no good winning even the majority of hearts, unless they care very, very deeply about the cause. The only path to success — and remember that SOME people are able to be successful — is through a disciplined tightrope walk. Without that, you may even succeed in terms of getting the ball rolling, but you’ll have a miserable time of it.

The hardest thing for STCAs to come to grips with is that politics, influence, and maneuvering are requirements for change in most orgs (short of an all out revolt, or mass exodus). You don’t have to be disingenuous, but you will have to work the people angle.

Assume that everyone is “on the same side”, but don’t assume deep trust from the outset. Probe, test, observe, map, and ask questions. Understand the resistance on a deep level before confronting it. Spend time with people who don’t share your mindset. Slow down to speed up.

Develop a clear vision and boil it down to its essence
“Be the change” in whatever way possible. Lead with results
Learn how to have crucial conversations
Patience and persistence
Develop strong relationships, even with those you disagree with

That’s about it for now. Do you have any other tips? Did this resonate on any level? Let me know in the comments below.

7 Tips For Better Prototypes

I love developing prototypes. I love the challenge of teasing out insights with asuper low-fidelity prototype. Most of all I like keeping…

7 Tips For Better Prototypes

I love developing prototypes. I love the challenge of teasing out insights with a[super low-fidelity prototype](http://www.smashingmagazine.com/2014/10/06/the-skeptics-guide-to- low-fidelity-prototyping/). Most of all I like keeping prototypes squarely focused on reducing risk, and making sure the process benefits the customer.

Too often I feel like the prototyping process becomes a blocker unto itself. Competing goals muddy the waters, confirmation bias rules the roost, and feature creep turns a throwaway prototype into a big undertaking.

Below are a couple thoughts on how to keep the prototyping process free from bias, and focused squarely on the needs of your customers.

1. Decide On A Driver

Is the prototype designed to elicit meaningful feedback? We build prototypes because we lack decision-making information. A shotgun approach makes it difficult to filter the signal from the noise. Consider instead building multiple prototypes that individually address key areas of uncertainty. Decide on a driver. Is your goal to experiment with different technical approaches? Are you validating usability, adoptability, or business value? Prototypes don’t multi-task well. “All of the above” is not a great answer. Stick to a single driver, and at most a “nice to have” side benefit.

2. Defeat Confirmation Bias

Ask how the data you intend to gather will ultimately change your behavior. Most people assume they’ll “just know” when they’ve nailed a feature. Right off the bat that thought process is setting in motion a strong confirmation bias. As I’ve mentioned in previous posts, there is a big difference between exploratory testing (where you’re looking for unexpected failures and successes) and validation tests that are designed to validate a system is working correctly.

Can you move the needle with a single, low-lift enhancement? That would be a good one to try first because an affirmative response would be surprising, and therefore valuable. Also, consider having someone with less skin in the game lead the validation efforts with users. You might already be too close to your solution.

3. Throwaway Prototype?

Are you willing to throw away your prototype and start over? Make it clear if you’re building a [throwaway prototype](http://blog.codinghorror.com/the- prototype-pitfall/) meant to be discarded, or an [evolutionary prototype](http://www.exforsys.com/career-center/project-management-life-cycle /the-evolutionary-prototyping-model.html) meant to be refined and rebuilt into the final solution. The middle ground is not a great place to be. A throwaway prototype lets you work quickly and focus on the big, risky unknowns. An evolutionary prototype focuses on better understood features and delays decisions on less clearly understood features. If you are juggling unknowns AND knowns in a single feature, then consider running two prototyping tracks in parallel.

4. Simplicity

Don’t prototype a more complex feature, when a simpler feature might achieve the same effect. Why? Even cheap complex features can have an adverse effect on the user experience and make future iterations more difficult.

5. Small and Timeboxed

Keep the team small and [timebox](http://www.techwell.com/2014/01/use- timeboxing-boost-your-efficiency) your efforts. The value of prototyping is that you discover information quickly and cheaply. All too often this turns into a prototyping death march, where vague feedback triggers a never-ending escalation of complexity, minor iterations, and increasingly vague and misleading feedback. Don’t go there! Cut it short. Don’t expand the scope because you lack clear feedback. If anything, remove variables. Stick to discreet questions and areas of uncertainty.

A small expeditionary force keeps you lean, and defeats analysis paralysis. A timebox keeps you focused, and forces you to paint with a limited palette.

6. Tweaking vs. Prototyping

Differentiate optimization/tweaking from prototyping. Are you 90% of the way there? Then by all means release your feature and tweak. Are there large, lingering areas of uncertainty? Then continue to prototype. The team should have a solid sense of turning the corner before releasing code to a broad user-base. The larger sample size will help when it comes to optimizing and detecting small differences. But processing broad feedback at scale can be difficult. And why wait that long to root out problems that can be more easily and cheaply caught earlier in the process? Broad strokes first. Fine print last.

7. Have A Plan

Don’t pressure teams into prototyping for the wrong reasons. I’ve caught myself in the past using the “fail fast / learn” mantra to justify cranking out poorly planned prototypes. The reality was that I wanted something sexy to show customers, and that I didn’t really have a plan for testing my assumptions. Don’t let this happen. Have a plan. Engage with your team to uncover what is blocking data-driven decision making, and together plan the prototype. If you are making the executive decision to “just start building”, then at least be transparent about that.

Let me know what you think in the comments below! Happy prototyping!

Inside My Kindle: 100 Books For PMs, UX, Entrepreneurs, Systems Thinkers,

Design Thinkers, and…

I’m a product development nut. And I’m a book junkie. I love this stuff. I recently moved to Raleigh, NC (from always blissful Santa…

Inside My Kindle: 100 Books For PMs, UX, Entrepreneurs, Systems Thinkers,

Design Thinkers, and Other Crazies (Like Me)

I’m a product development nut. And I’m a book junkie. I love this stuff. I recently moved to Raleigh, NC (from always blissful Santa Barbara, CA) to work at Pendo.io, a startup focused on helping product managers build awesome products. You can find me on Twitter at @johncutlefish.

It occurred to me today that my Kindle collection was starting to get pretty large. Poking around Amazon I realized that you can actually get a list of all your purchased books. It isn’t a perfect list (the titles are cut off), but it gives you enough information to find the book. The kicker was getting an email from a friend asking for some book recommendations. So I decided to share the current state of the book list with her (and you).

This covers the topics that interest me: leadership, UX, startups, cognitive bias, product management, Agile, management, complexity theory, marketing, design thinking, system thinking, data, analytics, hypothesis-driven development, product development, self-improvement, communication, organization design, lean, kanban, collaboration, and generally figuring out ways groups of people can continuously improve and build useful stuff.

I’ve read each of these books. I’m a big believer that there is never a magic bullet. None of these books presents the definitive “way”. Where there is a “why” (and inspiration, and rigor, and an open mind), there are a host of tools that can help get you there. Choose wisely.

Books

**#Workout: Games, Tools & Practices to Engage People, Improve..
**Jurgen Appelo
**100 Things Every Designer Needs to Know About People (Voices..
**Susan Weinschenk
**Agile Business: A Leader’s Guide to Harnessing Complexity
**Bob Gower
**Agile Experience Design: A Digital Designer’s Guide to..
**Lindsay Ratcliffe
**Agile Product Management with Scrum: Creating Products that..
**Roman Pichler
**All Edge: Inside the New Workplace Networks
**Clay Spinuzzi
**Antifragile: Things That Gain from Disorder **(Incerto)
Nassim Nicholas Taleb
**Behind Closed Doors: Secrets of Great Management (Pragmatic..
**Johanna Rothman
**Being Wrong: Adventures in the Margin of Error
**Kathryn Schulz
**Blinkracy: A Step-by-Step Guide to Make Any Company..
**Sebastian Klein
**Bootstrapping Using Services: Entrepreneur Journeys
**Sramana Mitra
**Buyology: Truth and Lies About Why We Buy
**Martin Lindstrom
**Conversion Optimization: The Art and Science of Converting..
**Khalid Saleh
**Crucial Conversations Tools for Talking When Stakes Are..
**Kerry Patterson
**Data Driven Design: How Today’s Product Designer Approaches..
**Phillip A. Harris
**Designing the Conversation: Techniques for Successful..
**Russ Unger
**Disciplined Entrepreneurship: 24 Steps to a Successful..
**Bill Aulet
**Do More Faster: TechStars Lessons to Accelerate Your Startup
**Brad Feld
**Don’t Make Me Think: A Common Sense Approach to Web..
**Steve Krug
**Drift into Failure: From Hunting Broken Components to..
**Sidney Dekker
**Ending the Management Illusion: How to Drive Business..
**Hersh Shefrin
**Exponential Organizations: Why new organizations are ten..
**Salim Ismail
**Founders at Work: Stories of Startups’ Early Days
**Jessica Livingston
Getting Results the Agile Way: A Personal Results System for..
J.D. Meier
**Getting to Yes with Yourself: (and Other Worthy Opponents)
**William Ury
**Habit Stacking: 97 Small Life Changes That Take Five Minutes..
**S.J. Scott
Holacracy: The New Management System for a Rapidly Changing.. Brian Robertson
**How Google Works
**Eric Schmidt
**How To Be The Luckiest Person Alive!
**James Altucher
**How to Change the World: Change Management 3.0
**Jurgen Appelo
**How to Make Sense of Any Mess: Information Architecture for..
**Abby Covert
**Impact Mapping: Making a big impact with software products..
**Gojko Adzic
**Implementing Lean Software Development: From Concept to Cash..
**Mary Poppendieck
Influence (Collins Business Essentials)
Cialdini PhD
**Inspired: How To Create Products Customers Love
**Marty Cagan
**Intertwingled: Information Changes Everything
**Peter Morville
**Interviewing Users: How to Uncover Compelling Insights
**Steve Portigal
**Joel on Software
**Joel Spolsky
**Kanban
**David J. Anderson
**Kanban from the Inside: Understand the Kanban Method,..
**Mike Burrows
Lean Analytics: Use Data to Build a Better Startup Faster..
Alistair Croll
Lean Change Management: Innovative practices for managing..
Jason Little
Lean Enterprise: How High Performance Organizations Innovate..
Jez Humble
Lean from the Trenches: Managing Large-Scale Projects with..
Henrik Kniberg
Lean Marketing for Startups: Agile Product Development,..
Sean Ellis
Lean UX: Applying Lean Principles to Improve User Experience
Jeff Gothelf and Josh Seiden
Learn or Die: Using Science to Build a Leading-Edge Learning..
Edward D Hess
Lessons in Agile Management: On the Road to Kanban
David J Anderson
Let’s Stop Meeting Like This: Tools to Save Time and Get..
Dick Axelrod
Life is Short And So Is This Book: Brief Thoughts On Making..
Peter Atkins
Little Bets: How Breakthrough Ideas Emerge from Small..
Peter Sims
Management 3.0: Leading Agile Developers, Developing Agile..
Jurgen Appelo
Measuring the User Experience: Collecting, Analyzing, and..
William Albert
Mindset: The New Psychology of Success
Carol Dweck
Nail It then Scale It: The Entrepreneur’s Guide to Creating..
Nathan Furr
No One Understands You and What to Do About It
Heidi Halvorson
Once a Runner: A Novel
Parker Jr.
**Personal Kanban: Mapping Work | Navigating Life
**TonianneDeMariaBarry
Pitch Anything: An Innovative Method for Presenting,..
Oren Klaff
Poke the Box
Seth Godin
Positioning: The Battle for Your Mind
Al Ries
Predictably Irrational, Revised and Expanded Edition: The..
Dan Ariely
Purple People Leader
Chester Goad
Quantifying the User Experience: Practical Statistics for..
Jeff Sauro
**Reinventing Organizations: A Guide to Creating Organizations..
**Frederic Laloux
Rework
Jason Fried
Rocket Surgery Made Easy: The Do-It-Yourself Guide to..
Steve Krug
Running Lean: Iterate from Plan A to a Plan That Works (Lean..
Ash Maurya
Scaling Up
Verne Harnish
Scrumban: Essays on Kanban Systems for Lean Software..
Corey Ladas
Self-Reliance
Ralph Waldo Emerson
Seven Databases in Seven Weeks: A Guide to Modern Databases..
Eric Redmond
Signals and Boundaries: Building Blocks for Complex Adaptive..
John H. Holland
**Statistics Done Wrong: The Woefully Complete Guide
**Alex Reinhart
Switch: How to Change Things When Change Is Hard
Chip Heath
**TAPE SUCKS: Inside Data Domain, A Silicon Valley Growth..
**Frank Slootman
Team Geek: A Software Developer’s Guide to Working Well with..
Brian Fitzpatrick
The 8 Qualities of Drama Free Teams: Do More. Stress Less
Dennis McIntee
The Dip: A Little Book That Teaches You When to Quit (and..
Seth Godin
**The Fifth Discipline: The Art & Practice of The Learning..
**Peter M. Senge
The Hard Thing About Hard Things: Building a Business When..
Ben Horowitz
The Human Side of Agile — How to Help Your Team Deliver
Gil Broza
The Innovator’s Hypothesis: How Cheap Experiments Are Worth..
Michael Schrage
The Leader’s Guide to Radical Management: Reinventing the..
Stephen Denning
The Lean Mindset: Ask the Right Questions
Mary Poppendieck
The Lean Startup: How Today’s Entrepreneurs Use Continuous..
Eric Ries
The Mythical Man-Month: Essays on Software Engineering,..
Frederick P. Brooks
The Open Organization: Igniting Passion and Performance
Jim Whitehurst
**The Power of Habit: Why We Do What We Do in Life and..
**Charles Duhigg
The Principles of Product Development Flow: Second..
Donald G. Reinertsen
The Startup Owner’s Manual: The Step-by-Step Guide for..
steve blank
The Ultimate Hitchhiker’s Guide to the Galaxy
Douglas Adams
The User Experience Team of One: A Research and Design..
Leah Buley
The War Of Art: Winning the Inner Creative Battle
Steven Pressfield
Thinking in Systems: A Primer
Meadows. Donella
Thinking, Fast and Slow
Daniel Kahneman
Tough Sh*t: Life Advice from a Fat, Lazy Slob Who Did Good
Kevin Smith
User Interface Inspection Methods: A User-Centered Design..
Chauncey Wilson
User Stories Applied: For Agile Software Development..
Mike Cohn
User Story Mapping: Discover the Whole Story, Build the..
Jeff Patton
Web Analytics 2.0: The Art of Online Accountability and..
Avinash Kaushik
Why Information Grows: The Evolution of Order, from Atoms to..
Cesar Hidalgo
Why Plans Fail: Cognitive Bias, Decision Making, and Your..
Jim Benson
Wiser: Getting Beyond Groupthink to Make Groups Smarter
Cass R. Sunstein
Work Rules!: Insights from Inside Google That Will Transform..
Laszlo Bock
Working Identity: Unconventional Strategies for Reinventing..
Herminia Ibarra
Zero to One: Notes on Startups, or How to Build the Future
Peter Thiel

Thanks! Did I get anyone’s name wrong? Do the links within Medium work? Did I miss someone? Do you have other recommendations? Let me know …

Dr. Obvious, Startup Validation, and Failure

“Validating” your startup is a big buzz word lately. Heck, all you need is five minutes and a napkin. I think the term is misused.

Dr. Obvious, Startup Validation, and Failure

“Validating” your startup is a big buzz word lately. Heck, [all you need is five minutes and a napkin](http://www.inc.com/jessica-stillman/validate-your- startup-idea-in-5-minutes-or-less.html). I think the term is misused.

**Validation **is doing tests for which you are trying to confirm some piece of information. Exploratory tests involve doing tests for which you gain value with both failures and successes. The difference is absolutely critical for startups. Simply validating commonly known information does little to produce privileged information. The real winners discover that twist: the UI that drives adoption, the untapped enterprise market, or the untested viral growth strategy. Why waste valuable resources on proving the known?

You are approaching validation (or what I prefer to call exploration) correctly if you get negative responses (failures) about 50% of the time. In the exploratory stage the most valuable learnings come with unexpected failures and unexpected successes.

Why? In The Principles of Product Development Flow: Second Generation Lean Product Development, Donald G. Reinertsen shows the following graph to demonstrate that the average information generated by such a test is a function of its failure rate:

This should look familiar to engineers as the theoretical basis behind the binary search algorithm, but for the rest of us Reinertsen explains:

The equation in Figure 4–6 shows that the information content of a test comes from the degree of surprise associated with each possible result. Any unexpected success has high information content, as does any unexpected failure. Unfortunately, most companies do a far better job of communicating their successes than their failures. They carefully document successes, but fail to document failures. This can cause them to repeat the same failures. Repeating the same failures is waste, because it generates no new information. Only new failures generate information.

The takeaway? At first, do more exploring and less validating. You are attempting to purchase information, and to maximize the value of that information you must design tests that fail as often as they succeed.

Easy Test: “Hand entering those receipts must be pretty painful huh?”

Hard Test: “Will you sign a year long contract for $22,000 if I can solve that problem for you?”

If every interview confirms your core assumption(s), then you are likely asking the wrong questions, or you are simply eliciting “known” information that is shared broadly and not particularly valuable. Like drug companies you are looking to perform tests that have unexpected results driving asymmetric payoff functions — not simply validating what is known, or failing for failure’s sake.

For example, almost everyone finds taxes, losing weight, balancing your checkbook, and home buying painful. This is why there are such large industries around solving those problems. A company like Mint didn’t need to validate that home budgeting was difficult. Rather, it needed to validate that you could disrupt with automation, bank relationships, take advantage of new bank APIs, and that there was a critical tipping point in terms of willingness to share financial data.

Some problems / pains are incredibly clear and poignant — they’ve been around for a long time — but the solution is elusive because you’ve got an “integration” problem. For example, take the music business. Everyone knew it was broken. Countless startups tried to address the problem. But it was Apple who side-stepped the integration / coordination problem.

Additionally, very few validation efforts take sufficient measures to avoid “leading the witness”. The confirmation bias is in full effect, and we likely only hear what we want to hear. We are literally “validating” ourselves vs. figuring how where there is an angle for a business.

Most pain is known. The trick is timing, understanding sea changes in terms of user habits, unraveling integration issues to force disruption, and developing faster/cheaper ways to do things. Write some scripts, stop leading the witness, and make sure your interviews are challenging your assumptions as often as they are confirming your assumptions.

Life, Death, Continuous Improvement, and Continuous Disruption

I’ve been thinking about (and hearing about) continuous improvement a lot lately. This past weekend I had the pleasure of attending my…

Life, Death, Continuous Improvement, and Continuous Disruption

I’ve been thinking about (and hearing about) continuous improvement a lot lately. This past weekend I had the pleasure of attending my first Agile Open event in Berkeley, CA. The experience was rewarding on multiple levels. Within a couple hours I had become part of an instant community of fellow Agile-nerds. Together we spontaneously created a 30 session 2-day unconference. And the supportive community helped me tackle topics I have been struggling with lately.

The following covers some new thoughts on continuous improvement inspired by Agile Open. New friends [Rob Carstons](https://www.linkedin.com/profile/view?id=AAkAAADF654BEZ7kgRiR- xxVME4TBa2_XgL4sA4&authType=NAME_SEARCH&authToken=rCbS&locale=en_US&trk=tyah&trkInfo=clickedVertical%3Amynetwork%2CclickedEntityId%3A12970910%2CauthType%3ANAME_SEARCH%2Cidx%3A1-1-1%2CtarId%3A1444631892156%2Ctas%3AROB%20CAR), and Chris Young really helped me germinate a vague idea into something more solid.

As Pablo Picasso once said, “every act of creation is at first an act of destruction.” Continuous improvement exists against a backdrop of atrophy, entropy, decay, adaptation, expansion, growth, evolution, and disruption.

Consider mitosis and apoptosis. With mitosis, cells divide and growth occurs. When a tissue or organ reaches the right size, the process slows. With injury (necrosis) or periods of growth, the process accelerates. Apoptosis, on the other hand, describes healthy cell suicide. The Greek word apoptosis refers to the “dropping off” of petals and leaves from plants and trees. When a tadpole becomes a frog it loses its tail. Billions of cells die in our intestines every hour. The human hand begins as a solid blob until the cells separating our fingers undergo apoptosis. And insufficient apoptosis results in uncontrolled cell proliferation (such as with cancer).

Continuous improvement is not a simple act of addition, and neither is growth.

At least from the perspective of shareholders, growth is key in the current tech landscape. A 2007 McKinsey research report titled Grow Fast or Die Slowdescribes the advantages afforded to high-growth companies:

They offer a 5x return to shareholders compared to medium-growth companies
The fastest growers (>60% when they reached $100 million in revenues) were 8x more likely to reach $1 billion in revenues than those growing less than 20%
They succeed despite margin or cost structure

This ecosystem is extremely volatile and out of equilibrium, with rapid technological change, cultural shifts, and cutthroat competition for resources. Growth is the goal; it has big advantages like greater capitalization, market share, mind share, and access to resources. But like the human cells above, the entrepreneurial muscles and tissues we create and grow exact a high metabolic overhead. Information flow is reduced. We spend more to manage dependencies and integration. We must eat and digest more resources to survive.

It’s not just about growth either: all players in the ecosystem are facing eventual disruption and extinction (see Joseph Schumpeter’s concept of creative destruction). Every day of growth and existence involves a potential parallel path of decay and atrophy. In this context, continuous improvement isn’t merely about keeping our skills up to snuff, or honing the rough edges of our Agile rituals and practices. It’s about survival. The dynamics of adaptation and evolution are the same, but the pace is massively accelerated.

Let me present the basic model we developed and played around with at Agile Open.

How does this work? Let’s start out with the basics:

In Steady State we are not improving, but we may be using newly improved capacities
With Disruption we experience a change in the equilibrium. We experience a stressor from an internal or external source
The first response is Pain
Pain reveals information. And we Learn
Learning leads to potential Improvements
We reach a local optima and move to a Steady State

We have four primary loops with three not-so-ideal end states:

Disruption and Pain predominate when we first encounter the stressor. If the stressor is large, then it leads to Death. The disruption and pain was too great
If we are in Pain, we may continue to Learn. But if we can’t translate that into Improvements then we will eventually reach Death. We are stuck in a downward spiral not being able to apply our learning.
When we combine Learning with **Improvement **we have a virtuous cycle that lets us translate disruption driven information into improvements. Eventually we’ll reach a local optima
Finally, in the Steady State loop we can simply “ride it out” for some period of time. Without further disruption we risk descending into a cycle of complacency, and finally Death.

This cycle is experienced on the individual, team, product, organization, industry, cultural, and multi-cultural level. Some examples:

**Individual. **We first exist in the womb, a decently safe steady-state. Birth is a form of painful disruption. We learn and adapt. Hit plateaus. And continue through the cycle. If we suffer a grave injury then we are disrupted and stuck in the pain cycle, and may die. If we get stuck in a steady-state, then we struggle with a form of atrophy and death. We work to improve our work environment until a certain point where things plateau. And if things stay there we get restless and then disrupt ourselves and find a new job.

Organization. After a period of smooth sailing our industry is disrupted due to an important cultural shift. If the disruption is too harsh, we die. If we live, we learn and adapt, and improve.

Teams. Team formation is a form of disruption. Hopefully we push through to a period of learning. We get diminishing returns from our improvement efforts. Cruise a bit. And then disrupt ourselves.

**Products. **Products are initially disruptive. We go through a period of optimization (learn / improve), and then move to maintenance mode. It is at this point that we either disrupt ourselves with a new offering, or let the competition do that for us.

In a single culture (and organization) you can have multiple parties moving at different speeds through this loop. Consider the example of the tenured engineer who starts getting bored due to fewer challenges, more rules, and less flexibility. They have achieved steady state. While the company is happy with the steady state, they are unaware that it is leading to complacency. Our engineer starts to get an itchy trigger finger. Either they will disrupt themselves and leave the company, or the company will respond.

Or the organization with leadership that can see the impending threat but has trouble inspiring a sense of urgency. Or the sector within the larger global landscape that is on the forefront of disrupting the incumbents.

With this model in mind, we can take a broader view of continuous improvement. Let us discuss the key levers an Agile Coach could use to impact flow through this cycle:

Assess the states of individuals, teams, the organization, industry, and broader culture (if working internationally). Where are they in the cycle? Do they realize where they are?
Preserve the safety of Steady State when it is helpful and when it help consolidate gains
Move people out of steady state to Disruption at the right time
Sense Pain quickly, soften pain of disruption, and shift quickly to Learning
Facilitate the Learn/Improvement cycle
Realize when a local optima has been reached for local improvement and push ahead

So let’s get back to continuous improvement. Gary Hamel refers to flexibility as “planned adaptation” for the “expected” and agility as “unplanned adaptation” to the “unexpected”. Flexibility, therefore, requires the ability to see the future which is rather difficult. Agility assumes an unknown future.

In the [Quest for Resilience](https://hbr.org/2003/09/the-quest-for- resilience) Hamel writes:

Strategic resilience is about having the capacity to change before the case for change becomes desperately obvious. An accelerating pace of change demands an accelerating pace of strategic evolution, which can be achieved only if a company cares as much about resilience as it does about optimization

He continues:

The goal is a company where revolutionary change happens in lightning-quick, evolutionary steps — with no calamitous surprises, no convulsive reorganizations, no colossal write-offs, and no indiscriminate, across-the- board layoffs. In a truly resilient organization, there is plenty of excitement, but there is no trauma.

Hamel’s version of resilience is similar to Nassim Taleb’s “antifragility”. Antifragile systems are not merely robust — able to withstand threats — but actually thrive in volatile environments.

With all this in mind, I want to propose a broader vision for continuous improvement that extends beyond surfacing and fixing sprint impediments and eeking the final 10% of craft competence out of a team. It’s the part of the puzzle that many companies miss when they buy into an Agile transformation only to be stymied with the next seismic shift in their industry.

Continuous improvement is the response to the drumbeat of atrophy and carrying dead weight. And it works hand in hand with continuous disruption. Basic process improvement and optimization relies on a repeatable future. Continuous improvement addresses a deeper need.

The goal of continuous improvement is to, at a minimum, grow today while remaining as Agile as you were yesterday. And even better: to increase that Agility during growth. This is not optimization. This is resilience.

In a sense that is what Agile Open was to me personally. A bit of disruption (a friend recommended that I attend and take the plunge), some initial pain understanding the format and getting comfortable, learning, improvement, reflection in the form of this post, and now I’m off to the steady-state (bed). Cheers!

Sticky Love — Choosing Between Physical Boards and Online Tools

I say both.

Sticky Love — Choosing Between Physical Boards and Online Tools

I say both.

tl;dr: Consider using both. Leverage online tools for what they do best.

The [physical board vs. online tool debate](http://pm.stackexchange.com/questions/8711/what-is-better-a-physical- scrum-board-or-an-online-board) has been a staple of my career for 5–8 years now. It changes form occasionally, and with each year there are new twists, but for the most part it has remained exactly the same. I’d put it up there with debates on wikis, ticketing systems, roadmap tools, and [chat clients](http://bunnyinc.com/blog/communication-tools-bunny-inc-hipchat- sqwiggle-google-sites-lost-us-slack-yammer-confluence).

So instead of repeating myself with each new instance of the debate, I’m just going to get my opinion out in one post. Below I’ve described some of the key advantages of physical boards and online tools. And then I go on to describe my preferred portfolio of three physical and non-physical tools. I’d love to hear your experiences in the post comments. What has worked for you?

Do physical boards scale? Sure. But I’m not a fan of scaling Agile (see Jurgen Appelo and [No. Agile Does Not Scale](https://medium.com/@jurgenappelo/no-agile-does-not-scale- 98df99da3ff3#.mv642sbw5) ). More than 100 people trying to work on the same product and mission should descale and focus on more defined and individual impactful goals IMO.

OK, let’s get started. By the way I had a seriously hard time deciding between using “online”, “digital”, “virtual”, “electronic”, or “software” for non- physical tools. So I settled on the imperfect “online”.

Physical Boards are great for:

Changing workflow on the fly to meet new challenges
Supporting and promoting continuous improvement
Supporting complex workflows that are difficult / inflexible to model with tools
Creative customization (mission, magnets, blocker flags, etc.)
Improving team collaboration, communication, and interaction (for collocated teams). See Tom Wujec’s TED Talks on visual problem solving:
Include items for UX (and other non-engineers) that are awkward to include in an online system
Team standups. The large canvas keeps the focus on the work (also see this post from Alexander Byndyu )
Adding upstream and downstream stages without clouding an online tool. When you deliver a feature is it truly “done”?
Taking screen breaks to improve focus, creativity, and energy levels
Easy work decomposition (“let’s just create another card”)
Discovering tool requirements before purchasing a tool
Preventing measurement dysfunction. Not all metrics from online tools are applicable in all situations, and many are abused
Boards can accommodate theme, epic, and story level views simultaneously which aids in mentally connecting epics and their stories

Spotify Agile Board (source: https://www.pinterest.com/pin/495396027732629779/ )

Online Tools are great for:

Asynchronous collaboration like comments, attachments, and notes
Integrations to third party tools (source control, devops, Slack, etc.)
Remote collaboration and being inclusive to remote team members
Home and travel access for co-located teams
More established and stable workflows
Teams that can afford extra large monitors for standups
Intra-company collaboration across functional teams (e.g. support, success, c-suite)
Automatically capturing metrics and generating reports (assuming these actually drive value for you)’
Work decomposition (“I’ll just type up a new card, and we wont have 200 cards up on that whiteboard”)
Encouraging edits to existing cards
Handling lots of cards / tickets

Online Kanban Board (source: <http://leankit.com/blog/2013/12/seeing-big- picture/>)

(see also [here](http://blog.nwcadence.com/kanban-boards-physical-or- virtual/), [here](http://www.agileweboperations.com/kanban-boards-physical-or- electronic), [here](http://toolsforagile.com/blog/archives/762/5-reasons-why- physical-boards-are-better-than-electronic-boards), and [here](http://jacoporomei.com/news/virtual-physical-the-best-of-two-worlds- for-our-kanban-board/)) for more Physical vs. Online posts

My favorite approach is something that combines the advantages of both. Mirroring the boards feels like overkill. It really isn’t necessary for day to day operations. But the advanced collaboration and integration capabilities of online tools are essential.

The problem with online tools is that they so quickly become unusable and bloated with repeated customizations. What starts with three stages becomes five stages. Projects multiply. Views multiply. The backlog has 500 items, and half of the authors have left the company. And most people come to eventually hate the tool (I’ve had teams hate Jira, Rally, Fogbuz, Pivotal, Bugzilla, etc.) You always end up hating the digital tool …

Not sure what he thinks now …

With that in mind, my favorite combination is something like:

A physical board to promote continuous improvement and collaboration along with a stamp to number the tickets on the physical board. Multiple teams might want to incorporate a portfolio Kanban board.
A ticketing system with MINIMAL customization (three ticket stages, and assigning ticket to a team member), used primarily for the third party integrations and asynchronous collaboration. I like Jira. But a ton of products will do the job here
A note-taking app (Evernote) or loose Kanban board (Trello) for collecting, tagging, and organizing customer feedback, notes, research, etc.

Why? Each does what it does well:

Physical Board: Continuous improvement, effective standups, and radiating information
Online Ticketing: Asynchronous collaboration and integrations
Online Note-Taking / Loose Kanban: Search, organization, tagging, exploring connections (see this wonderful video from Mailchimp’s Aaron Walter describing how they use Evernote)

I’d throw in a good chat client (Slack maybe?), because used well it actually reduces the number of costly distractions.

The pitfall of most tools is that they try to do too many things well. This is the bane of most online tools after 6–12 months of use and customization.

Together these systems take advantage of each tool’s strength while avoiding the weaknesses. A common trap with tools is that we tend to notice the deficiencies because they slap us in the face (“I have to walk over there and WRITE on that INDEX CARD!” or “What do you mean this doesn’t integration with Salesforce”) while the advantages are more subtle. Our expectation is that everything should be easy without acknowledging that most optimizations in one direction (e.g. information showing up in multiple systems) involve a sacrifice in another direction (e.g. sacrificing flexibility, and creativity).

The [note-taking app is an important componen](http://alistapart.com/article /connected-ux)t because both physical boards and online ticketing systems break down when you add 600 item backlogs. Neither are a good repository for ideas and lack the rapid search / access of Evernote or loose organization and workflow of Trello. Google Docs and Sheets work, but they become unwieldy with any amount of scale.

Some tips / guidelines:

Again, minimal customization of the ticketing tool. Think of this as the ticket repository
Always feel free to customize the physical board. That’s why you’re going to the trouble!
The stamp is clutch for keeping track of things. An alternative would be printing simple QR codes or barcodes that could integrate with the ticketing system (using a mobile app, for example)
Consider taking a photo of the Kanban board periodically (1x or 2x per day) for your remote team members. Or better yet rig up a time lapse photo
Open up the note-taking tool as broadly as possible across the organization. You want everyone to feel comfortable contributing
Consider a second physical board for roadmap / portfolio planning

That’s about it. What do you think? What has worked for you and your team?

104 Questions For Product Development Teams

Please bookmark this post. Don’t try to read it all in one sitting. You will hate me and call me crazy.

104 Questions For Product Development Teams

Please bookmark this post. Don’t try to read it all in one sitting. You will hate me and call me crazy.

It will not go well with your coffee. You will get distracted, and if you are a product manager it will likely trigger some anxiety. I could have written this in 10 posts, but I figured it would be easier to keep it all in one place.

After bookmarking the post, please do the following:

1. Email it to a trusted co-worker with one of these subject lines:

“What goes on in a product manager’s brain …. “
“Before we start the next project … “
“This is why I need a vacation … “
“Answering these questions can make our engineers happy … “

2. Read the introduction, and then browse ten (10) questions to get the gist. Then return to it when you’re in a bind, need to reality check your situation, or want some ideas on how to give your team more clarity.

Introduction

Let’s get started. To quote [one of my favorite posts on the role of product management](https://medium.com/@joshelman/a-product-managers-job- 63c09a43d0ec), the product manager’s job is to:

Help your team (and company) ship the right product to your users

Simple right? Hardly. I like to think that product helps the team (both the immediate “doers” and the broader team) achieve a state of Flow for the benefit of your company and users. Wikipedia defines Flows as:

… the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity.

Apathy, boredom, and anxiety are Flow anti-patterns. Clear goals, tight feedback loops, and the absence of blockers are Flow state prerequisites.

And they also happen to fit squarely in a product manager’s job description. In short, help the team focus all of its energy on driving value directly to the users/customers. Do “everything else”. And do so in situations that are often ambiguous and constantly changing. Servant leadership (without the authority) at its best.

Below I have documented 104 questions (@250 if you count the questions inside the questions) that I ask myself during an average day, week, month, and year. They revolve mostly around the internal facing role of product and promoting Flow. For some of these questions, it is my responsibility to have the answer. The team deserves no less. For others, I guide the team towards self- discovery. Either way, the focus is on clarity, and a clear path forward.

Team and Situation

What must I know about the team and situation before we really get started?

How experienced is the engineering team? How familiar is the team with the problem domain? How motivated is the team to address this problem?
Can we co-locate the team? If not, does the team have a strong track record of working remote, and are they committed to overcoming remote challenges?
Is the team comfortable with ambiguity?
Does the team want to be involved in the more strategic aspects of the effort? If so, what is their background in assumption/hypothesis driven development?
Is the team comfortable interacting directly with end-users and customers?
Is the team empowered to solve the problem autonomously? Is there typically a lot of healthy debate and push-back? Or is the team eager for someone else to make the difficult decisions?
Does the team possess a good mix of viewpoints, backgrounds, and communication styles? Or do some team members exert a disproportionate influence?
What is the history of the team? Are they coming off a positive experience with high momentum, or a negative experience with no momentum?
What is the history behind this effort? How has that history shaped current perceptions? Is this viewed as an “about time” project, or a “why the hell?” project? Have other teams failed? Why? If building on top of an old feature, why was the feature left in the current state? How will it impact the bottom line? Where is the product in the product lifecycle?
Who are the major stakeholders? How do the stakeholders view the problem? Have they already become emotionally attached to potential solutions? Am I already biased? What is the general consensus on the risks involved? Are there any agendas at play? If so, what is our plan to navigate individual agendas?

Goal And Vision

What is the big picture? Where are we going?

Are the business goals clear and actionable? Are goals framed as target outcomes?
How is our work tied to the goals of the business, and how will we measure our impact?
How is our work tied to the goals of our users/customers, and how will we measure that impact?
Have we communicated those goals with a compelling vision? Does the vision inspire and focus our work? Can it be explained in a tweet? What is our “true north” ? Is the team engaged?
As we discover new information, have we refined the goal appropriately?

Problem

What problem are we trying to solve?

Does the team have a shared understanding of the problem we are solving? Are we speaking the same language? Does the team have a shared understanding of the problem’s root cause?
Do we understand who we are solving the problem for? What are their needs? In their words, how do they describe those needs? Have we sufficiently researched our customer goals and pain points, including speaking directly with a minimum of ten customers (ideally with the team)?
How are customers solving the problem right now, keeping in mind that our biggest competition is often the status quo?
How much time and resources do we have to solve the problem? Are we running out of either? Do we share a similar sense of urgency? Do we share a high level idea of what we’ll be doing in the next week, weeks, month, and beyond?
How will we rightsize our solution to the problem at hand? At what point will the investment of more time and energy have a limited return?
If we are releasing a feature for an existing product, have we identified the feature as a basic must-have “table stakes” feature, a performance feature, or a differentiator? Have we validated this understanding, or are we operating with limited information?
Who are the team’s go-to subject matter experts (SMEs)? Are they available?
Have we injected the necessary awareness of the market, competition, market, and legal issues into our understanding of the problem? If not, what is the next step to gather that data?
Was the team involved in defining the problem? Do they feel vested and engaged? How can we help them become more vested and engaged?
Would some reframing of our goals and/or KPIs allow us to more effectively understand the problem from the perspective of the business? If this is impossible, is the team OK with the ambiguity? Is this a leap of faith, or a hesitant nosedive?
What would happen if we simply did nothing? Is that an option? Is there a possibility that the problem will solve itself, or the metrics will move without our intervention?
Have we framed the problem in terms of desired outcomes as opposed to possible solutions/features?
Have we leveraged all of our available sources of data to understand the problem, current workarounds, customer behavior, and competitive options?

Assumptions and Hypotheses

What are our knowns and unknowns?

What are our operating assumptions? Have we validated these assumptions? Does the team understand and share these assumptions? How will we test our untested assumptions?
How do these assumptions stack up in terms of risk? Who bears the possible burden of that risk? Which assumptions must we accept as givens, and which assumptions are open to testing and validation?
What are the constraints to our solution? For example, do we need to use an existing technology framework? Do we have to complete the feature in time for an annual convention?
What parts of the solution are negotiable? For example, could we reduce the breadth of features to release more quickly?
Have we discussed our individual biases? How do these biases impact our view of the problem, and our attachment to our proposed solution?
What is the current, single greatest threat to the project’s success? How will we defend against that threat?
Assuming that “not delivering the intended value to the customer” is our worst case scenario, what steps can we take to make sure that does not happen?
What is our biggest gap in knowledge at the moment? What do we need to learn now? What can we learn later? How can we learn quickly and cheaply? Can we restate these gaps as a series of well-articulated questions?
What piece of information/data impacting our work would we gladly buy if it was immediately available? Is it available? If not, how might we “purchase” that information by committing our resources?
What is the current working hypothesis in terms of a solution? Is there consensus among team members regarding our working hypothesis?
Was the team involved in generating the list of key assumptions, questions, and solution hypotheses? Do they feel vested and engaged? Did the whole team have an opportunity to state key assumptions impacting their area of expertise?
Could some of our questions be resolved by simply having clearer goals?
We likely will need to function amidst some level of ambiguity. Are we potentially overreacting to, or under-reacting to the perceived level of ambiguity?
Have we agreed on a process to track and iterate on our assumptions, risks, and questions?

Prioritization, Sequence, Delivery

How do we do the most important thing next?

Does the team have a shared understanding of our current priorities, and our near-term prioritization and sequencing of work? Are we in agreement that this is the best plan of action?
Is the sequence of how we intend to release our solution optimized for information gathering? Will it be possible to gather meaningful data given the scope of the incremental releases?
Have we effectively mitigated the risk of confirmation bias / tunnel vision for our solution?
What key decisions will we need to make soon? How will we make these decisions? Are we about to make any irreversible decisions, and if so, do we agree on the potential risks involved?
Is there consensus around which decisions can be deferred?
How will we decide which features are truly essential?
Is the team comfortable with the rough sizing (estimation) of prioritized items?
How will we decide that we’re done? If that seems a long ways off, what are some short term definitions of done? Are these goals specific, measurable, actionable, realistic, and time constrained?
Are we currently on a good trajectory to deliver the best solution possible given our current constraints?
Have we collectively agreed on when we’ll reconvene to reassess our progress?
To what extent are edge cases and newfound dependencies influencing prioritization? Is there a way to decouple our solution from these issues?
Have we acknowledged any technical debt we might introduce into the system? What is our plan for working down any debt caused by our solution?
Do we have a shared understanding of the target fidelity for the next iteration?
How large is our current inventory of untested and unimplemented ideas? How much rework would be required if all of our current inventory was found to be off-target?
How might potential disruption to customers guide our prioritization? Will the feature require training and “unlearning” old habits? Must we validate how we intend to launch the feature?
Was the team involved in prioritizing work and developing the guidelines around how work was sequenced? If their involvement was minimal, are they ok with that?
Does the sequence of work and current prioritization scheme pass rational muster with the team? Could the team repeat the prioritization and sequencing exercise and arrive at the same results? Is it a system that could be used in the future?

Users/Customers

How do we keep the solution relevant to customers?

Does the team have a working user/customer persona hypothesis? Is the persona visible?
What is the current customer attitude towards the problem? Is this something that users have been expecting for years? Or will the solution come as a welcome surprise?
How are we engaging our customers as we formulate and build a solution? How are we building empathy for their situation and goals? When and how, exactly, will we next share some aspect of our solution with customers?
When was the last time the team interacted with a “real live” customer? What did we learn? How can we learn more when this opportunity next presents itself?
Are we investing our time such that we are maximizing value to our customers? How would an average customer respond if they were to participate in our last meeting or last discussion? Would they call our work valuable? Is our work being described and framed in terms of its utility and value to customers?
At what point will we expose our solution to customers using their data, in their context, and with their day-to-day organic workflows?
Once released to users, how will we gather feedback such that it is actionable and timely? Do we intend to act on this feedback? Will our customers expect us to act on their feedback immediately?
Are our usability testing methods matched with the phase of the solution? Are they generating statistically significant data appropriate for the phase goal? Are we using a good mix of qualitative and quantitative methods?
How will we measure what our customers do in addition to what they say?
What challenges might we face when gathering customer feedback? How can we address these challenges?
Are we leveraging all available channels to gather customer feedback?
How will we make customers aware of this feature? Is this a feature with limited appeal to our customer base? How will we measure adoption as distinct from usability or feature/need fit? Is driving adoption of the feature in scope, and if so, what is the plan to drive adoption?

Dependencies

How do we manage dependencies?

Will our solution disrupt our customers in the short term? How will this be managed, and what data will we need to feel confident in our management strategy?
Are we communicating effectively to stakeholders outside of our team (sales, support, other teams, users, etc.)?
Are there legal /privacy implications?
Will our solution touch other parts of the product? Are we at risk of negatively impacting the user experience elsewhere?
How and when are we playing “three dimensional chess” as we seek to resolve dependencies? Are we discounting the simplest path forward?

How We Work

How does the team stay efficient and healthy?

Do we have clear agendas for the next week’s worth of meetings? Do any meetings need to be repurposed to meet current challenges? Can any meetings be canceled?
Are meetings managed for maximum utility? Who documents the decisions and action items resulting from meetings? Are they conducted in conducive settings, with the right tools and participants?
Is the product owner available at all times?
Do we have a clear idea of individual responsibilities? When there are overlaps, have we discussed potential conflicts?
Does our team have the requisite information to make most decisions regarding the solution autonomously? Or, are we losing cycles due to ambiguous goals?
Are we limiting the amount of extraneous and “noisy” data? Does the team feel protected from any competing agendas and politics?
Are we calling things by the same name? Have we developed a common vocabulary to discuss our solution, the problem, and our assumptions?
Do we have momentum? Is that sense of momentum and progress shared by all members of the team? Can the team focus on doing instead of strategizing? Is everyone inspired? Is anyone unclear about what their week looks like? Is momentum building or waning? How can we recover from a recent drop in momentum?
Is anyone on the team blocked? What can be done to remove those blockers? Is our process suffering from any bottlenecks? What can be done to remove those bottlenecks?
Is the team suitably buffered from distractions and disruption?
Does the team feel focused and productive? Are we having fun?
Is the work suitably decomposed so as to limit work in progress? Does the team share a solid definition of done?
Has the team formalized its hand-offs, stages, and agreed upon process?
Have factions formed within the team and, if so, are these factions healthy? Do different points of view drive value to the customer, or should we work to reduce personal bias? Can we harness these differences for good? Can any back-channels be made public?
Is the team collaborating and communicating in an effective manner? Are tools being used consistently?
Can I provide adequate information to other stakeholders regarding the status and focus of the effort? If a rough schedule is required, is that available? Are we maintaining a burndown chart? How does my work fit into the overall roadmap?
Are all sources of information — including ticketing tools, wikis, documents — up to date? Do stakeholders have necessary access? Can extraneous information be removed for clarity?
Are our emails clear, actionable, and scannable?

Off The Rails?

What happens when things go off the rails?

What does my gut say?
Am I the blocker? If so, how can I change that?
Is there animosity on the team? How can we dispel that immediately?
Am I doing my absolute best to build a shared understanding for all aspects of the project? Am I doing so without dragging the team “through the mud” ?
Beyond presenting data and sound reasoning, am I providing inspiration?
Are we actually shipping?
Can I see the forest through the trees? Can the team?
Are my actions creating an environment of trust and ownership? If I am second guessing the team, can I find a productive way to express my concerns?
What does the team need right now? Did the team crack at least one joke today? Lighten up! Time for beers.
Am I taking care of myself? Eating well? Sleeping well. It all counts?

Conclusion

Did anyone make it this far? Really? Please comment.

Good Process, Bad Process

To most people the word “process” might as well be a four-letter word.

Good Process, Bad Process

To most people the word “process” might as well be a four-letter word.

At some point in our career, most of us have encountered a misguided attempt at “big bang” business process re- engineering. Or a mind-numbing, soul-sappingTPS-style approval process (approved in triplicate!) Or the introduction of the latest hot development approach.

But I see process in a different light. When I think about process I think about things like the creative process, the learning process, transparent and collaborative problem solving, information processing, and evolution and mutation. My thoughts drift to design thinking, surfboard shapers, and bespoke tailors. I just don’t share the visceral reaction.

In this post I would like to address two common assumptions:

That process is by definition rigid and inflexible
That process is by definition “top down” and overly dogmatic

I’ll start by giving a couple examples of process at work.

Checklists sound awfully controlling. But, by using a checklist surgical teams can ”significantly lower the number of deaths and complications” regardless of the type of surgery.

But even a small change, like having surgical team members take a moment to say who they are and what they do before scalpel touches skin, can have important consequences later on should one of them develop a concern during the operation. Earlier studies have shown that communication problems are fairly common in operating rooms, with junior members of the team sometimes hesitant to speak up.

While a staff psychologist with the Israeli military, [Daniel Kahneman (Think, Fast and Slow)](http://www.amazon.com/Thinking-Fast-Slow-Daniel- Kahneman/dp/0374533555) describes how his team disrupted the common practice of assessing new recruits. Instead of relying on intuition and a comprehensive assessment,[Kahneman introduced a new process consisting of a simple 5 point quantitative survey](http://www.businessinsider.com/daniel-kahneman-on-hiring- decisions-2013-1#ixzz3l6otUHal).

What he came up with was so controversial it almost caused a mutiny. Kahneman asked interviewers to put aside personal judgments and limit interviews to a series of factual questions meant to generate a score on six separate personality traits. A few months later, it became clear that Kahneman’s systematic approach was a vast improvement over gut decisions. It was so effective that the army would use his exact method for decades to come.

At Henry Poole [“each new client is a fresh and unique canvas to us”.](https://henrypoole.com/history-of-henry-poole-tailor-of-savile-row/the- story/) Their “cutters” use a time honored bespoke process to craft custom tailored suits.

With each piece of clothing being made personally by our tailors on the premises on Savile Row, London, the theme remains consistent: individuality expressed through craftsmanship and style.

Improv groups use a basic process [to guide the scene while keeping things “unusual” and interesting](http://www.pantheater.com/articles-rules-of-improv- part-i-improv-comedy.html).

Characters need to go on journeys, be altered by revelations, experience the ramifications of their choices and be moved by emotional moments. We go to the theater to see the unusual days characters have, not the everyday moments of stasis and stagnation.

The scientific method (as described by this teacher) “is the process by which scientists, collectively and over time, endeavor to construct an accurate (that is, reliable, consistent and non-arbitrary) representation of the world”.

Alistair Cockburn describes the “heart of agile” in four simple words: collaborate, deliver, reflect, and improve. Which is remarkably similar to the [learning process](https://teaching.unsw.edu.au/understanding-learning- processes), and the Deming Circle (PDCA).

Four processes form the “basic mechanisms” of evolutionary change: mutation, migration, genetic drift, and natural selection.

The creative process invites experimentation, and iteration. In describing the making of Bitches Brew (Miles Davis), [Author Paul Tingen quotes drummer Jack DeJohnette](http://jazztimes.com/articles/20243-miles-davis-and-the-making-of- bitches-brew-sorcerer-s-brew):

This was the beautiful thing about it. He’d do a take, and stop, and then get an idea from what had just gone before, and elaborate on it, or say to the keyboards ‘play this sound.’ One thing fed the other. It was a process, a kind of spiral, a circular situation. The recording of Bitches Brew was a stream of creative musical energy. One thing was flowing into the next, and we were stopping and starting all the time, maybe to write a sketch out, and then go back to recording. The creative process was being documented on tape, with Miles directing the ensemble like a conductor an orchestra.

The point I’m making with these examples is that process itself is not the problem. Trying to demonize the concept of a series of steps towards an outcome is like calling breathing an anti-pattern. Calling it by some other name: craft, practice, “way of working”, method, and ritual is more palatable for the process phobe, but we often are discussing the exact same concept.

Thinking on the examples above, a good process …

Represents the current tactic with full knowledge that the tactic may change
Attempts to eliminate individual biases and groupthink
Allows us to reflect on what is and isn’t working using both qualitative and quantitative data
Allows for iteration
Is explicit and transparent … everyone knows what we’re trying to accomplish, minimize, and maximize
Encourages variability and conformance when it is most valuable
Engages the participants and players in an inclusive fashion by harnessing them as sensors and actors
Is repeatable relative to the diversity of inputs and desired outputs
Does not usurp and try to control the collective intelligence of your team

I’d like to end by discussing discipline and process. Alistair Cockburn has a great YouTube video on disciplined Agile which inspired this line of thinking.

We often equate discipline and process with rigidity. It just sounds inflexible. Cockburn claims that “lazy Agile” is surprisingly effective, but that we can do better by exploring different methods, and processes. Yes this discipline has more “process” (a couple more box and arrow diagrams), but it is no less (and perhaps even more) “Agile”.

A disciplined approach can be extremely flexible (you don’t see MMA fighters throwing up their hands due to the variability of their opponents). And the disciplined team — just like the disciplined improv group — knows when to break the rules and explore a new process.

The truly agile organization resists the temptation to oversimplify. Like surgeons with their checklist it evolves processes to de-bias decisions and applies discipline (the good kind) and process where it will have the most leverage. This approach empowers all layers of the organization to experiment with and evolve the current tactic while making the tactic transparent and explicit. When modifying open source code we check out the “code” (the process), iterate, and check back in improvements for testing. It is egalitarian but disciplined.

In closing, I’d encourage readers to define and practice process (under the guise of any word, really) in a way that generates results and introspection for your team and organization.

Everything should be made as simple as possible, but not simpler
Albert Einstein

I wouldn’t give a fig for the simplicity this side of complexity but I’d give my life for simplicity on the far side of complexity
Oliver Wendell Holmes

Product Ownership: 10 Core Principles

When you boil it down, what does it take to be a great product owner? It’s easy (and tempting) to overcomplicate things. Often we focus on…

Product Ownership: 10 Core Principles

When you boil it down, what does it take to be a great product owner? It’s easy (and tempting) to overcomplicate things. Often we focus on the “higher level” aspects and theory of the function, and forget the basics. In my mind, it all centers around your relationship with your team.

10 Core Product Ownership Principles

Build trust. Without the trust of your team you have nothing.
Respect your team, your customers, and your partners
Prove your worth. You aren’t a status-checker along for the ride. You have a function (multiple functions actually). Do the work to build trust, build respect, and empower the team.
**Outcomes over features. **Focus on delivering great outcomes to your customers. Nothing is more discouraging for a team than delivering great software that no one needs, or not knowing whether your work had impact.
Communicate efficiently. Boil everything down to an actionable message. You are the noise and distraction filter. Synthesize ruthlessly so others don’t have to.
Build an action framework. Provide the data, direction, and exposure necessary for autonomous decision making. Let the team take credit for their solution.
**Decide and facilitate appropriately. **Sometimes the team needs a decider. Sometimes the team needs help making a decision. And sometimes you need to just get out of the way. Act accordingly.
Run great meetings.
Focus on team needs. How can you help your team today? What do they actually need? Focus there.
**Have fun. **If you view product ownership as a battle between you and the team, then no one will have fun. Keep it light and positive.

That’s it. Not too complicated. But no one said it would be easy!

Juggling Growth and Usability: A UX Debt Primer

The concept of technical debt is generally understood. But what happens when we extend the concept to product design and user experience…

Juggling Growth and Usability: A UX Debt Primer

The concept of technical debt is generally understood. But what happens when we extend the concept to product design and user experience? Can an interface accumulate debt? And what can we do about it?

Technical Debt Primer

The now well known metaphor technical debt was coined by Ward Cunninghamto describe both the intentional and unintentional accumulation of loose ends in software design. Taking the metaphor too literally gets you in trouble (and can derail any meeting, especially with engineers), but the general idea is that at some point all organizations have to “pay off” the debt through a deliberate allocation of resources, “write off” the debt by starting over, and/or suffer the consequences.

Lucky companies play the balancing act to perfection, foregoing key decisions until the last possible moment, while benefitting from current knowledge and data. Unlucky companies eventually take a big hit, falling behind competitors as they struggle to dig out. And negligent organizations inject debt haphazardly, without any quantitative sense of the debt being accumulated or the interest rate.

Agile, XP, and Technical Debt

One thing that agile does very well is to iteratively address customer-focused features. When paired with extreme programming (XP) practices, such as test-driven development and pair programming, agile does a decent job of hedging against certain forms of technical debt, and striking that fine balance between speed, quality, and cost. Evolved teams dedicate some percentage of resources to the [gradual reduction of debt,](http://deloitte.wsj.com/cio/2014/03/04/reversing- your-organizations-technical-debt/?mod=wsjcio_hp_deloitte) and use sound design principles (e.g. system decoupling, design patterns, etc.) to ease the pain. So for technical debt, we have some models for success, albeit with a lot of debate in the engineering community.

UX Debt

The discussion becomes a bit more complicated when we discuss the concept of UX debt. What happens when we accumulate baggage in our product design and interface?

[Lean UX](http://www.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of- the-deliverables-business/) practices have done a great deal towards integrating design into the agile process, with a strong focus on cross-team facilitation, less up-front design, and tighter collaboration between engineers, designers, and other usability/design oriented disciplines (like researchers, information architects, etc.)

But many designers will admit to a nagging worry. The thought that keeps them up at night is whether the whole product experience is the best it can be, and when will they need to pay off the debt incurred during rapid, feature-focused design. If big upfront design is dead, then how do we create cohesive user experiences in a flurry of discrete features?

The Symptoms

UX debt can be recognized by some of the following symptoms:

The interface fails to gracefully absorb new features (tab overload, action overload). Remember Amazon prior to the 2011 redesign?
Design patterns are highly specialized, linear, and task based (which isn’t surprising given the features were built based on user stories)
Customer blindness to new features. Interface does not encourage natural exploration of new features
Inconsistency with regards to interaction patterns, information architecture, and UI components. For new users this causes significant cognitive load
Difficulty adapting interface for new screens, new applications, new integrations
Heavy coupling between the presentation layer and backend. “Re-skinning” the whole product, or similar components across product, is difficult or impossible
Addressing usability issues in “green field” type projects, while ignoring UX issues in core flows in the product. This typically suggests some technical limiters / blockers when it comes to refactoring the UX.

A key takeaway here is that accumulating design debt is not inherently bad. There might be perfectly good reasons why your company exhibits these symptoms, and chooses to focus elsewhere. Design is certainly not the only discipline to be sacrificed in the quest for speed to market and growth (think gathering data, tools to speed customer service, etc.). The trouble is that UX debt is often poorly understood and misvalued. It just starts to “feel” wrong, without any quantitative metrics to prove otherwise.

Lack of Forcing Function

As with technical debt, the difficulty here is that there is rarely some “do or die” moment that acts as a forcing function. Big tidal shifts like the rise of mobile, or a violent loss of market share do happen, but most of the time things don’t move that fast.

Like a sailboat picking up barnacles and kelp, the slowdown can be barely perceptible, until impacts start to accrue exponentially (as is common with highly dynamic systems like interfaces). Going from 8 mph to 7 mph takes a while, but suddenly you’ve dropped from 7 mph to 4 mph, and you need to turn into the wind, pull down the sails, and send someone overboard to address the issue. And it is never easy: existing customers seldom welcome redesigns with open arms, even if you are making the product more generally usable.

Invisible

Another problem is that UX debt is often invisible (which is rather counterintuitive considering it is the central touchpoint for the customer). Engineers seldom use all the product features on a regular basis. And UX debt just doesn’t hit home like failing systems and code modules. Customer support staff, while often being expert users, adopt workarounds. Especially in B2B products, there exists a general sense that users can be “trained” to adopt suboptimal flows. And finally, and probably most importantly, humans have trouble noticing slight changes. The product design literally changes under our noses, until something big and serious happens. This often comes in the form of a competitor who offers superior design and ease of use, while we’re left struggling to keep up.

Usability Testing

Usability testing in the context of agile development often focuses solely on the feature in question. Tasks are developed, and the participant is asked to proceed through a task while talking out loud. Like an architect building extremely comfortable rooms with awkwardly placed doors and lights, it is possible for flows to test well while remaining unusable and inconsistent within the context of the whole product. The agile focus on tested usable features delivered quickly is immensely valuable, but doesn’t inherently address consistency and general usability.

A Continuous Juggling Act (And Some Tips)

The juggling act never ends. The best strategy is one of quantification, informed risk mitigation, and building awareness of the issue. The integration of UX on agile teams is relatively new, and there simply might not be a full appreciation for the risks involved. Cataloging missing features is old hat, but understanding why the holistic design strategy matters is a relatively new challenge. To get the discussion going, I’d like to present a few possible strategies to make UX debt real, address it early, and build awareness across the team:

Always test your product with people who fit your customer profile, but who are not current customers. Do your best to avoid theanchoring bias whereby the standard for excellence is the current product. Think of this as TDD (test driven development) for product design. Ask yourself how you can develop a repeatable process to assess whole-product usability by user role.
Establish usability benchmarks against commonly used products both in your domain and outside your domain. And test your product against those benchmarks. Time to completion for tasks is informative only when relative to the time it would take the same user to complete a familiar task. In many domains with late adopters, it can be easy to trounce the competition from a usability perspective. But remember that your customers will evolve and establish new benchmarks. Mobile is a major catalyst in terms of turning late adopters into power users with high UX expectations.
Catalog components in your software and categorize by pattern, application, visitor traffic, and whether they are on the critical path to key conversions. Many teams are unaware of just how many variations they have developed
Find a way to quantify your UX debt. Options could include combining the results of benchmark tests (both customers and non-customers), customer feedback, and inline surveys. The emphasis here is getting buy in for your methodologies across the team, and making the accumulation (and pay off) of debt visible
Leverage pattern libraries and frameworks for DRY UI development.
Assume that the interface will change. Trends will develop. Technologies will develop. So how will you consistently offer the best user experience possible? Approach this challenge in partnership with your engineers, and adopt practices in systems design that will allow an architecture to emerge
Discuss the risk with your team. UX is a new addition to agile teams, and ways of working are still be ironed out. An exercise might involve a pre-mortem, whereby team members discuss how ignoring UX debt might derail the team at some future point.
Establish checkpoints and regular design reviews to recognize when redesign or refactoring of the interface is required. Involve the whole team
Dedicate some part of every sprint to working down UX related debt

What Do You Think?

How do you address whole product experience in the context of agile/scrum/lean (insert buzzword here) ? Let me know in the comments.

User Stories and Data

I frequently hear questions like …

User Stories and Data

I frequently hear questions like …

“How do you know what to measure?”
“How do you write data stories?”
“Where do we even start?”

One approach is to write data-specific user stories. These stories often look something like this:

Data stuff. See John

That’s not great. Though it is a placeholder for a conversation which is a good user story pattern. I’ll give it that. One step up is to try something like this:

As a product development team, we can measure the rate of successful adoption for the new widget maker so that we can optimize the experience for customers

This is decent. But something is missing. Where is the direct value to the customer? And if you’re like most teams this type of story will be an afterthought. Which makes perfect sense. User value (and user personas) comes first.

I prefer to take another approach. Incorporate data into each and every story.

Think for a moment about the “T” in the popular INVEST acronym (a way to remember and assess what makes a good User Story). User stories are supposed to be Testable. We go to great ends to write unit, functional, and integration tests. But how about testing our basic hypotheses? Or that the story is meeting user expectations and driving the expected value?

User acceptance testing to the rescue! Well, sort of. Wouldn’t it be great if everything worked as smoothly as this [Stackoverflow](http://stackoverflow.com/questions/4904096/whats-the- difference-between-unit-functional-acceptance-and-integration-test) snippet:

If the tests pass, it means the software should meet the customer’s requirements and the stories can be considered complete. An acceptance test suite is basically an executable specification written in a domain specific language that describes the tests in the language used by the users of the system.

Great. Fire up that domain specific language. When your executable specification passes you’ve got a winning feature! Mark it complete! And keep that velocity rolling. Cue my favorite user story from real 1st hand experience:

As a product manager, I can see the [Feature Name] feature finished in two weeks, so that I can approve it

Joke? Almost. Keep in mind that the Scrum basically relies on a customer, or customer proxy, to sit there and “approve” the feature. You’re done at the end of the sprint when someone nods and says “yes”. And then the feature disappears off into the ether. **Out of Sprint, out of mind! **Or at least into the hands of business analysts.

But acceptance tests give a valuable hint. Let’s take a look at a [popular acceptance test format](http://codesqueeze.com/the-easy-way-to-writing-good- user-stories/):

Given [context] And [some more context]… When [event] Then [outcome] And [another outcome]…

Sure this format can be used for the low level aspects of a story. But take a broader view. We’re making assumptions about:

Context: The problem context or situation
Events: Events taken to rectify the problem
**Outcomes: **What outcomes result from attempts to solve the problem

Consider this example from a great, new, product idea I just had:

Example: GIVEN that people are perpetually in need of social gratification,AND THAT they enjoy seeing news from their friends, WHEN they encounter a “feed” of friend related news-snippets, THEN they will spend hours online, and may even click on ads.

Bingo! You have some clues for what to measure. You have context, events, and outcomes. Now validate!

[Alexander Cowan puts it bes](http://www.alexandercowan.com/best-agile-user- story/)t:

It’s silly to hold your nose, take the plunge and hope you’re right. It’s practical and effective to max out what you can know without spending a lot of time and money, start with the simplest possible implementation of a new feature, and then have an explicit plan to get a definitive result about its relevance. This is how a lot of actual innovation happens- effective experimentation (aka effective trial and error).

When I suggest this approach, the first question I typically hear is something like:

This is all good in theory, but Scrum says I need to mark the job complete at the end of two weeks. And that we’ll ship it. There is no place for this experiment! And we’ll never finish those stories if we actually add the tracking.

To that I would ask whether it is better to do the 20% that matters, or the 80% that doesn’t. Which brings up my final point. Taking a more data-centric approach is actually not about the tools, or even how you write stories. It is about something more fundamental.

Do you have dedicated, cross-functional, problem focused, and outcome driven teams? And do they actually control the destiny and shape of their work? Are they allowed to fail sometimes? And are they incentivized for output and utilization (being busy) or generating results?

Answer those questions and address any issues there (easier said than done), and then find a way to work in the data stories. My preference is to place them immediately in the user-centric stories or epics. Keep it lightweight, and similar to acceptance tests. Add some baselines and targets. And then use Kanban or another tool to pass the stories out from the sprint, and into a measure/learn flow. You may be “done”, but the story isn’t “Done” until it has achieved the desired intent.

10 Questions For Your (Product Role) Interviewer

It’s that nervous time of the product manager interview. You’re tired, need to re-caffeinate, are worried you don’t have enough “domain…

10 Questions For Your (Product Role) Interviewer

It’s that nervous time of the product manager interview. You’re tired, need to re-caffeinate, are worried you don’t have enough “domain experience”, and have just had to calculate the number of[ airplane passengers currently airborne in the United States](https://www.quora.com/How-many-people-are-in-the-air- flying-at-any-given-time).

The dreaded question is coming … “do you have any questions for me?” Oh crap!

Let me try to flip the script for you. You are interviewing this company for the opportunity to have you work there, and not the other way around. Product Management is extremely org-specific. It’s the perfect example of product/market fit (with you being the product). What works in one company will leave you burnt out, ineffective, and maligned in the next. It is vital that you find a place where you can thrive. So use this opportunity wisely.

During the hiring process there may be a lot of talk about empowerment, ownership, and customer-centric thinking (sidenote, if you hear the one about the mini-CEO just leave immediately). Are they putting lipstick on a pig and rolling out a gravity challenged magic carpet? Or describing your next dream job? Below I’ve listed 10 questions to ask when the interview tables are turned. Be curious and respectful, and let’em rip.

Knowing what you know at the moment, what weakness might I need to work on if I were to get this job? How would we go about structuring opportunities to improve on that weakness?
If you were to hire a product manager internally from another department/group, what is your best bet at the department they would currently work for? Why?
How would you rank the following in terms of your overall priorities: speed, rigor, quality, harmony, outcomes, and empathy ?
Are there recurring sources of tension between functional groups in the organization? Are they healthy? If so, how do you make sure they stay healthy?
How does your approach to product differ from that of your competitors? Who do you admire in your space (or another domain)? How are you differentiated?
Has the product team established any core values? What are they? Could you tell me a story or two that would help me understand those values? How has the role of product management evolved here over the years?
Let’s say I was to go out and ask one of your engineers about their relationship with the product team … what would they say? What would be their foremost gripe? How would they describe the value you deliver to them personally?
If the 80/20 rule holds true (and it tends to), what is the 20% of my work that will generate 80% of the value? Where will I have the most leverage in my day-to-day work? How do you help the team focus on this area?
In Geoffrey A. Moore’s Crossing The Chasm he mentions a Technology Adoption Lifecycle comprised of three primary markets: Early (Innovators and Early Adoptions), Mainstream (Early Majority and Late Majority), and Late (Laggards). Where is the product and market currently? Where will we be in a year? How will the team and dynamics change as we make this transition?
What is the most frequently misunderstood aspect of the product role internally? And how do you work to bridge that misunderstanding?

Choose wisely, or better yet just let the freak flag fly. There is no hiding in product management. If you are passionate about what you do then don’t plan on just flying below the radar. Don’t plan on things changing (they rarely do). PMs are always above the radar and exist at the confluence of major forces and pressures in the organization. So choose wisely!

Go forth and find the right match!

Shameless Pitch: When you’re there, consider giving Pendo (my employer, and an all around swell place to work) a try to guide the team towards better collaborative decisions and improved user experiences. We’d get to work together and you could give blistering and honest feedback to make our product great.

Hidden Costs of the Sales-Driven Roadmap

Exploring the cost side of the Sales Driven Roadmap

Hidden Costs of the Sales-Driven Roadmap

Exploring the cost side of the Sales Driven Roadmap

This deal is at risk until we can ____________

Are you ranking these requests by the revenue opportunity?

They won’t renew unless we _________

Can we schedule a meeting to review the following RFP points?

As a product manager in the B2B space you’ll inevitably run into a situation where sales is pressuring you to prioritize work to close a deal or retain a customer. It’s a dance Sales, Product, and Customer Success repeats over and over (picture a clumsy threeway waltz or polka). Cue the conference call feedback, twenty page RFPs, and rushed impromptu cross-team standups.

It’s a challenge. You are customer focused. You have empathy. But somehow the cost vs. reward feels off and you can’t prove it. Don’t give up so soon. Consider the following …

Growth Driver

Before jumping into thinking about costs let’s get one thing out of the way. At the end of the day you might not be too concerned about costs simply because controlling costs isn’t the focus. The underlying assumption for most growing businesses is that costs can eventually be controlled. Revenue and growth is king (see The Single Biggest Determinant Of Startup Valuations At IPO). You’ll read the impacts below and say “that’s all good, but we need to hit a growth goal”. I respect that. But I’d challenge you to consider instead the potential drags on innovation and agility. These are blockers to growth and should be considered. Keep reading …

Bias Petri Dish

It’s easy to rationalize the broad appeal of a feature request. We’d need to do this eventually, right? Other customers and prospects will need this if Acme needs this, right? There are a bunch of cognitive biases at play here including the availability heuristic, base rate fallacy, clustering illusion, sunk cost bias, confirmation bias, and conjunction fallacy. These manifest as follows:

The prospect is representative of other prospects and customers
The prospect’s needs are not specif. They are general
The prospect request is equally valued by other customers and prospects
Meeting the prospect request will actually result in a satisfied customer
We’ve invested a lot of time and money in cultivating this prospect so …
This run of requests represents a trend

We’ve all been victims to these biases in our personal and work lives. You can’t escape. As a species these instincts have served us well for the most part. However, the prospect request is straight out of an MIT behavioral economics study. It hits so many pressure points that most of us are basically screwed. It’s as if you combined the lottery, your love life, and probability in a petri dish. What’s the point here? You’re not seeing things clearly and your intuition is suspect.

Net Loss

Off the bat you’re at a net-loss if you invest $50,000 in engineering and product resources to deliver a feature which will increase your revenue by $100,000. Why? Isn’t that a profit? No. Not even close. The code will need to be maintained and will add to the complexity of the overall codebase hindering future velocity and innovation. Features need documentation, sales training, marketing, and support. And we’re not even talking about the other costs associated with that $100k of revenue (acquisition, on ramping, etc.) No one “accounts” for these costs. They rarely exist on a balance sheet. But they’re real and will bite you.

User Experience Impact

Imagine an aging hotel. Hallways disappear into nowhere. The light switches are never in the right place. It takes ten minutes to get to the pool. The Internet is spotty. Countless new additions create a sprawl that is difficult to navigate.

Welcome to the world of most enterprise software. You can get by for a while … heck, the “user” didn’t even cut the check … but you can never truly escape. This costs is extremely difficult to quantify but we’ve all, at some point, been on the receiving end of enterprise software that truly sucks usability- wise. And when a disruptor pops up that shifts the script we’re all the more willing to embrace the alternative.

Customer Need

The prospect has a list of requirements. Lists of requirements feel comfortable. They’re relatively easy to write — heck, just add a couple points for good measure. Someone owns this decision and by golly they’re going to own it. As someone involved in buying tools I can say without doubt that the requirements process is simply broken. It’s aspirational. Big and heavy RFPs are a recipe for failed implementations and software detritus. They may close deals, but they are not a leading indicator of long term adoption. In the heat of the moment it’s tempting to treat the RFP as gospel and the byproduct of careful research. It rarely is. The customer may rave about your responsiveness at first, but they might not be any happier in a year.

From an Agile perspective this is a big “requirements upfront” anti-pattern:

Looks simple huh? ([Source](http://sunnibrown.com/2009/05/rfp-evaluation- process-map))

As someone with UX Research experience I can say beyond a doubt that lists of features rarely address true needs. They jump to the What before the Why.

Value Proposition

If one feature is the deciding factor between the buy or pass what does that tell you about your business and product? Consider tools that solve a unique pain incredibly well. We get frustrated as users. We have to invent workarounds to make up for missing features. But we use it anyway because it does something incredibly well. If you’re battling over RFP bullet points consider the game you want to play. Are you battling over commodity features?

Opportunity Costs

This one is simple. By working on one thing you are by definition not working on something else. What are you sacrificing to attend to the prospect request? What could you build or explore given those resources? What is the value of doing this now vs. two months from now?

Distractions & Multitasking

External requests typically involve a lot of multitasking. There are endless cycles back and forth between sales, product management, and engineering. It’s hard to get the right people on the phone. You’re at the whim of conference calls. Just when you think you’ve nailed down the request someone else pops up and peppers your understanding like a gattling gun. Conservatively the team is at 50% effectiveness and it seeps into their other responsibilities.

Product development teams also feel the pinch. Prospect requests are typically run in parallel with existing roadmap driven work. It takes 3x the amount of time to finish two parallel tracks. SImply put, your team runs slower.

Conclusion

Hopefully that gives you some food for thought. I currently work for Pendo.io, an analytics tool with in-app guide and messaging functionality. One of the unique selling propositions of Pendo is that we record user activity retroactive to install. In the rush to crank out customer requests it can be prohibitive to add metrics and measure uptake. Our customers use this feature to reality check their intuition. Sure, the deal closed, but did anyone end up using it? Did it impact customer satisfaction (measurable with our in-app surveys and funnels)? The cost to answer these questions is low which in turn improves your team’s intuition in the face of bias. Until the costs are real, the debate will always swing towards Sales and the immediate prospect request.

Hope this has been helpful. Follow me on Twitter at @johncutlefish to keep the conversation going.

The Way Of The Product Whatchamacallit

Behold the Product Whatchamacallit! The who? Who knows? The Internet sure doesn’t.

The Way Of The Product Whatchamacallit

Behold the Product Whatchamacallit! The who? Who knows? The Internet sure doesn’t.

What does it do? Does it have a tail? Does it own or manage? Mini-CEO or minion? Who knows!? The Internet sure doesn’t. Maybe this dolphin does. Nope.

Ever feel like a smart dolphin utterly confused by Product Management?

But I’ll tell you about a recipe. It’s simply, simply simple!

Ingredient #1

Find a bunch of motivated hackers, builders, crafters, makers, designers of all stripes (coders are designers, also), inventors, and visionaries. Trust them, they’ve got a lot in common. Don’t separate them into departments. Departments are for Sears and Macy’s.

Together We Make Stuff. And Trust The Other People Know Their Shit

Ingredient #2

Start talking to humans together, observe their problems, and ponder how to solve those problems. Build a bit. Test your assumptions, tweak, and repeat. Sell it. And talk to those salesamajigs. They’ve got feelings too.

Mind Your Business

At this point hopefully you are all still “the business”. The product is everyone’s business, not some distant group of people who sit in a frosty windowed conference room dreaming up the work you’ll do for the next year (and claim you’re still empowered to solve the problem). Fight for this for as long as humanly possible. Decentralize. Look skeptically across the room when someone says that you (codeword engineering and UX) just need to “execute on the roadmap” and then doles out projects.

The Sorcerer And The Magic ProjectMap

The Product Whatchamacallit

So you are still The Business. It’s Your Business To Mind. Your Product To Mind. Phew. Even then, there will probably be some need for a Product Whatchamacallit, but the role will be much more helpful and tangible. She’ll be a person the team would hire if they controlled the budget (not such a crazy idea, actually). Because that person will DO helpful stuff and earn their keep, not just lubricate the three creaky gears of your org.

If you happen to be that lucky person -- and trust me this isn’t the standard “recipe for burnout, can’t wait till I’m in biz dev or strategy” role -- then read on. Embrace the Whatchamacallit Way.

Maybe? Could it be?

The Way Of The Product Whatchamacallit

Show empathy NOT indifference
Ask why and who NOT how and what
Serve teams NOT agendas
Be guided by principles NOT plans
Be a team-member NOT a team-driver
Focus on challenges and needs NOT titles
Treat teammates like creative makers NOT resources
Provide context and data NOT solutions and platitudes
Have suggestions and opinions NOT demands and fiats
Be curious and open NOT dismissive and stubborn
Harness diversity NOT conformity
Embrace simplicity NOT oversimplification
Deliver outcomes and impact NOT features and output
Build less NOT more
Be transparent NOT opaque or manipulative
Be accessible NOT elusive or overbearing

Together we deliver valuable outcomes and delight the humans who use and pay for our product, and the business and team will benefit. We’ll feel good about our work, and customers will come up to us in airports when we wear our shwag t-shirts and thank us.

Our handy dandy trust laden Kanban magnets

Go forth Whatchamacallit ! They’ll tell you “it’s not that simple”! Ask Why five times and see where you get …

This PM Hack Saved Me 1 Hour A Day (and helped me connect with more

customers)

How I saved an hour every day, stopped wasting my team and customers’ time, and gathered valuable insights and feedback from our customers.

This PM Hack Saved Me 1 Hour A Day (and helped me connect with more

customers)

How I saved an hour every day, stopped wasting my team and customers’ time, and gathered valuable insights and feedback from our customers.

**Image by **petradr

As a product manager (with strong UX tendencies) I start to get very anxious if I’m not talking to customers daily. I don’t discriminate between qualitative and quantitative data. It’s all valuable. Spend too much time looking at charts, graphs, and tables, and you’re liable to to lose sight of the “Why” and the story.

Enter the product manager’s arch nemesis: time management. Scheduling calls is a hassle for all parties. It’s terrible UX and I hate wasting customer time. Building a research panel / customer panel with survey data is all well and good, but it often fails to sift the signal from the noise. You often chat with customers [who don’t actually use the feature or don’t fit the profile](http://www.uxmatters.com/mt/archives/2010/07/recruiting-better- research-participants.php). Or worse yet you just focus on the “vocal minority” instead of the [silent majority](https://www.box.com/blog/building- products-vocal-minority-or-silent-majority/).

Enter in-app targeting and online booking tools. At Pendo we love to [dog-food our own product](https://beatrixapp.com/blog/6-months-of-dogfooding-our- software.html). Our guide targeting functionality allows fine-grained targeting based on activity, feature usage, and external data (from Salesforce and other integrations).

Below I’ll walk you through the ingredients for a recent real-world use case. My goal was to set up meetings with customers to discuss their “jobs to be done” for our guides functionality. What decisions do they make daily? How can we help them do their job more effectively?

Ingredient 1#: An In-App Guide

In this example I used the standard Pendo lightbox template with a simple call to action. Keep the copy light and appreciative. “Schedule It!” is a good CTA because it conveys the ability to complete the task without human assistance. I prefer this approach to email because it reaches the customer in-context when they are more receptive to the guide copy and request for feedback.

Ingredient #2: Targeting

I targeted this guide to frequent users of our guide detail page (guide details page viewed > 5 times). This is case where casting a wide net is NOT ideal. You want to screen your interviewees, and limit the disruption to visitors who don’t match your screening criteria.

Ingredient #3:A online booking app.

I suggest YouCanBookMe. Some important features are: setting a recurring lunch break, specifying work hours, appointment lead time (min and max), etc. This will make your life easier. The YCBM free version allows a single booking profile, but still manages to add appointments to my calendar. From a customer standpoint, the experience is pretty intuitive. They click on the button in the guide and see this:

Outcome

Out of 50 of our customers who saw this guide, 10 booked appointments. A 20% response rate for research requests — qualified real world users, no less — is pretty awesome. Consider an email campaign with 30% open rates and 30% response rates and we’re talking a ~2x improvement with no hassle. I didn’t need to send a survey to a panel. I didn’t litter people’s email inboxes and play email tag. And this all occurred on the “customer’s terms” and at their convenience. Our sessions were more productive and focused without the typical scramble around booking. Best of all, the data was more actionable for the team.

Give it a try! My philosophy is to talk to customers daily. You need to reality check your assumptions daily and, to [quote Steve Blank](http://www.inc.com/steve-blank/key-to-success-getting-out-of- building.html), “get out of the (virtual) building”. When you cut the scheduling insanity, this suddenly becomes MUCH easier.

As Product Managers We’re Asking Ourselves The Wrong Set Of Questions

Stop trying to define product management. It’s a fool’s game.

As Product Managers We’re Asking Ourselves The Wrong Set Of Questions

Stop trying to define product management. It’s a fool’s game.

Stop defining yourself by what you aren’t. What do you care about? How do you want to work with the people around you?

When reading articles about product management you frequently encounter words like “chameleon”, “[whitespace](https://medium.com/@danielfschmidt/a-map-of-white-space-for- product-managers-17d65c397749)”, and “[glue](http://onproductmanagement.net/2009/06/22/why-do-we-undermine- ourselves/)”. “It’s complicated!” Product Management is described by what it isn’t (e.g. [project management](http://www.huffingtonpost.com/brian-de-haaff /the-product-manager-vs-pr_b_8040402.html), [scrum master](http://blog.aha.io/index.php/the-product-manager-vs-the-scrum- master/)) or by how it is expressed in the context of a domain or methodology (e.g. in Agile, in B2B, in SaaS, in Lean Startup).

… surfing the Google in search for answers

I’ve been in teams that — after a year — still couldn’t describe the value the PM/PO brought to the table. The answer was to keep regurgitating the same posts and books …. as if to say “see, we DO something! I’m valuable because Intercom or Marty Cagan said so!”

In 2015 I attended three conferences where the best presenter jokes were PM/PO jokes, and the audience of UXers and Engineers ate it up.

In my view we’re asking the wrong question. We’re replacing a tough discussion of values and principles — as a whole team, not just as product managers — with discussions about titles, job descriptions, the org chart, and handoffs. The best perspectives on product development [have nothing to do with defining and boxing a title](https://medium.com/@stewart/we-dont-sell-saddles-here- 4c59524d650d#.w2rffmxtb). Stewart Butterfield doesn’t mention the word “manager” once but you walk away from reading that knowing he gives a damn.

It’s gotten to the point that I don’t recommend product management to hungry, entrepreneurial, and creative young people. I advocate for the various hats occasionally worn by PMs, but caution against the “title”. **I suggest User Experience or Engineering. **There’s a community of practice and a less weighty chip on the shoulder.

Consider what a young associate product manager wrote me the other day:

My boss is the VP of Product. She has needs and pushes me. Then the team. wants to do a good job. I feel them. So do I, but I have all this other crap to consider. I want to be customer-centric but Sales keeps pushing product. I’m pushing back all day. I deflect shit. The team kinda resents me. They don’t see 80% of the shit I deal with. It is this juggling act. I am a juggling act … I don’t even know what “product” means anymore …

That pains me as a lover of building great products. My bet … she’ll leave the industry in 6 years. Tops.

As Product Managers we insist on describing what we aren’t or what we connect (how/what) instead of what we value (the “why”). Values are lofty, but we fail to take a stand.

That extends to how we want to be with our fellow product development teammates. And with that, I offer my personal values and principles as they pertain to working with teams. **Your values / principles will vary (**these appeared first in my post [The Way Of The Product Whatchamacallit](https://medium.com/@johnpcutler/the-way-of-the-product- whatchamacallit-9929a78d6694#.ln3zzv6sf) )

Show empathy NOT indifference
Ask why and who NOT how and what
Serve teams NOT agendas
Be guided by principles NOT plans
Be a team-member NOT a team-driver
Focus on challenges and needs NOT titles
Treat teammates like creative makers NOT resources
Provide context and data NOT solutions and platitudes
Have suggestions and opinions NOT demands and fiats
Be curious and open NOT dismissive and stubborn
Harness diversity NOT conformity
Embrace simplicity NOT oversimplification
Deliver outcomes and impact NOT features and output
Build less NOT more
Be transparent NOT opaque or manipulative
Be accessible NOT elusive or overbearing

What are your values as they pertain to collaboration? What do you care about personally? Beyond what you aren’t … what are you? Start there. And then worry about the bullets in your job description and the platitudes of “customer first”, “connective tissue”, and “balancing acts”.

50 Interview Questions For B2B SaaS Customer Research

A no-nonsense list of of questions for B2B SaaS Customer Research

50 Interview Questions For B2B SaaS Customer Research

A no-nonsense list of of questions for B2B SaaS Customer Research

This is an audio cassette

I’m going to jump straight in …. I’ve got a lot of customer interviews coming up in the next week ([I blame in-app scheduling](http://blog.pendo.io/2016/01/22/this-product-manager-hack-saved- me-one-hour-a-day-and-helped-me-connect-with-more-customers/)) and figured that it was a good time to put some pen to paper. First some context:

Interview Goals

Know customers and their “jobs to be done”
Focus on problems vs. solutions

Remind customers that …

They can’t hurt your feelings
Your job isn’t to sell them, market to them, or take their feature requests
There are no right, wrong, or stupid answers
You’re happy to address support questions after the interview

Interview Tips:

Use words/phrases like “show me”, “tell me that story”, “what’s a real world example of that”, “why”, “who”, “how come”, “tell me more”, “how do you do that right now”, “sketch that” etc.
Be comfortable with awkward silences
Talk less as a rule. Let the customer do the talking.
Be aware of nonverbal cues, and “leading”. Take a deep breath and smile. Repeat words to yourself to stay in the zone like “curious”, “observant”, “patient”, “open”, “non-judgmental”, and “respectful”. Write these down as reminders
Use an audio recorder so as not to distract the customer. Or have a notetaker

Notes from a recent meeting …

Commence!

The Questions

Important: In these questions Acme is your product or brand. “You” is the customer.

If you weren’t working as a/n [customer title] what would you be doing?
If you had one work-related superpower what would it be? How would it work? Every superhero has a weakness. What’s your weakness?
If Acme was a brand of car, what would it be? Why?
What is the least understood aspect of your job? Why?
What is your unofficial job title?
If you’re comfortable chatting about non-work things … what hats do you wear outside of work?
Draw me the informal, real-world org chart of your department. How are things really connected? How does **it really get done?
Describe your personal aspirations for your career. What are you looking for in terms of career development? What’s the next big hurdle? What strengths will you leverage?
You have a magic ball. Money is no object. You can pick three metrics to put up on big monitors all over your team’s workspace. What are those numbers?
Some things have a tangible value associated with them. Other things are intangible. What is an example of an extremely valuable — but completely intangible — aspect of your job I should understand?
Describe a piece of software that gets out of the way and lets you get your work done. Now describe something that just manages to get IN your way all the time. What is the differentiator? Where does Acme fit in?
You’ve had a tough day. You pick a song that characterizes how you feel. What song do you pick? After feeling sorry for yourself you crank up a song to move forward. What song do you pick?
What “sixth-senses” do you have? How did you learn that intuition?
When was the last time — outside of software vendors, but at work — that you experienced incredible customer service from a vendor? Why?
A workaround is when you can’t initially get something done with the tools available, but you improvise and make things work. Describe a workaround from your work in the last month? How did you figure that out? Can you think of an Acme example?
What is the most important lesson you’ve learned from working with YOUR customers? Any nuggets of wisdom there? How have you applied that to your day-to-day work?
We all wear different hats during the day. You might be the “The Practical One” and then shift to “The Innovator” or “The Facilitator”. Imagine that you’re three different people, and that you juggle those three different personas each day. What would those hats be called? How do you act when you wear that hat? What is important to you?
Most movies have that montage scene about 2/3rds of the way through when everything starts moving. It occurs immediately before the final obstacle materializes. Let’s say that movie is about your work and this organization. Tell me the story there. Walk me through the feel-good montage, and end with the big obstacle.
Imagine a dream day here. Everything goes right and works smoothly. You’re in a state of flow and have a big smile on your face. Walk me through that. What is the biggest leap of faith in that description?
Complete this sentence … “I hope Acme doesn’t screw up and ________________” . How could we become something that you hate? Where would we go wrong?
How is your job performance measured formally and informally?
No need to provide the details, but what are the last three big decisions you’ve had to make here? How did you go about making those decisions?
What’s the last innocent — but damaging and disappointing — mistake that someone made while using Acme? Tell me the story there. What was the impact?
Have you ever had a SFW work-related nightmare? What happened? Is it a recurring dream?
Everyone has blindspots. In your opinion what is Acme’s blindspot when it comes to understanding you and the job you need to get done?
Who do you interact with most frequently on a day-to-day basis? What are you collaborating on? What is the output?
There is a major budget cut and software must go. You’re down to the bare essentials. You have to rank the importance of Acme between 1: Absolutely Essential and 10: Absolutely The First To Go … where are we at? Why? Who is ahead us and behind us?
Describe a conversation where Acme came up “at the watercooler” … one positive, and one negative. What was the story?
It’s Sunday and you have that sinking fear about work that’s keeping you from relaxing. What are you worrying about?
What is the meat and potatoes (or veggies and seitan) of your business?
You have a new employee at the company. You’re giving them the lay of the land, describing the tools they’ll use, and how they’ll use them. You have to describe Acme. How do you describe us to the newcomer?
How would you rank the following in terms of your personality and work style. Do you prioritize: 1) Efficiency, 2) Creativity, 3) Accountability, 4) Flexibility, 5) Resilience , or 6) Influence? Why?
For most jobs there is the “theoretical” way something gets done … it is nice and neat and tidy. And then the “real world” way it gets done. Can you draw me a flowchart of both? How does the real world differ?
If you could automate one part of your job (and keep your job) what part would that be? What would you do with the extra time?
It is twenty years ago. Replace Acme with a person who got this work done. What would that person’s title be? What is their job description?
I’ve got ten cards here describing different things you can do with our product. Without saying anything — it’s best if we don’t talk, and remember you can’t hurt my feelings — I’d like you to draw a frowny face, smiley face, or a deadpan face on each card describing how you feel when you use that feature. And then I’d like you to sort them in terms of how important they are to your day-to-day job.
Think about the other software tools you use. Fill in the blanks. Compared to ________ Acme is doing a great job, but compared to __________ Acme has a lot to learn.
Acme is a restaurant. What is it like eating there? What do we do well? Where do we fall flat? What is your best/worst dish?
I’d like you to take a quick stab at writing the new Acme marketing tagline. It is short and snappy. It cuts to the chase. What is it?
Times are tight and we are all busy. If you had more budget for your department, and more time to focus, what would you spend that money and time on?
Imagine you’re at a meeting discussing our product. People are relaxed and speaking candidly. We’ve done a good job and have met your needs. Complete this sentence … “Acme has paid for itself many times over by ___________________ “.
Have you ever used a piece of software that left you feeling that the developers didn’t actually try the feature? What’s that area of Acme? Where are we clueless? What’s a train wreck?
Trust is earned. How can we earn your trust? How can we lose your trust?
It’s one year from now. You’re responsible for creating a report card to decide whether to renew your contract with us. What’s on that report card? And where do we sit right now? Let’s draw it out …
When was the last time you celebrated as a team because of something work related? Why?
For most jobs you can let a lot of stuff slide in the short term. But there is something that simply MUST happen. If you don’t deliver in that regard you’re screwed. What is that “one thing”?
This is your moment to shine. You are presenting to the whole company. You’re about to show the magic slide … the slide that rocks everyone’s world, secures your raise, and turns you into a rockstar. Can you draw it for me? What would it say? What are the three bullets?
We’ve all witnessed purchasing fails over the years … that one software tool that got everyone super excited but then failed to deliver. Without naming names, could you briefly describe the “promise” (what you hoped the purchase would achieve), and then the reality when the rubber hit the road?
How would you disrupt your own business if you could? You get to start over and tear it all apart. Where are things going?
Describe an intractable problem from your work world … something that no amount of work, research, meetings, and discussion — formal and otherwise — can seem to fix. What is the sticking point?

Persona(s) Non Grata

Saving the persona from itself, from selfish UX, and other tips

Persona(s) Non Grata

Saving the persona from itself, from selfish UX, and other tips

An engineer once described a persona exercise as “theater camp”. I thought about that for a while and realized what she was getting at. Here I was coming from the UX world, running the team through a song and dance exercise with imaginary people, stickies, and line drawings. The “creative” (me) felt comfortable — I was in my element — but to the attendees it was like a nightmarish new-age UX drum circle.

It’s like a wrestler doing their first yoga class. Or me doing pair programming or trying TDD. I tell the one about role playing games being the inspiration for personas. Crickets. My jokes fall flat.

[Role Playing Game Character Sheet aka Persona](http://markdangerchen.net/papers/coordination-cooperation-and- camaraderie-in-world-of-warcraft/world-of-warcraft-the-role-playing-game/)

One solution is to retrench and to consider personas as the UX rallying call. People are going to play along whether they like to or not, embrace my powerful UX Empathy! But I think that is shortsighted. I’ve experimented, and have found some things that work.

Yes. They’re Fake

Personas have a shaky reputation among software engineers. And that’s being generous. I’ve been in numerous situations where teams openly (and forcefully) expressed their distrust, dislike and aversion to personas. Mini revolts ensued and hand drawn posters faded and magically disappeared. One engineer described personas as the “Joe The Plumber”-ification of software development. Ouch.

In the words of engineers they seem “fake”, “contrived”, “artificial”, and “forced”. It would be easy to write this off as a lack of empathy or imagination (which ironically is reverse lack of empathy), but in my experience the opposite is true. Teams genuinely want to connect with users. The reality is that personas, at least initially, are all of those things — fake, forced, and contrived — while at the same time being extremely valuable.

The reality is that personas, at least initially, are all of those things — fake, forced, and contrived — while at the same time being extremely valuable.

Pick a character from a favorite book. You’re pulled in by the story. At page one-hundred of John Steinbeck’s _Of Mice and Men _we know Lennie and George well enough to predict impending doom when they meet Curly (and Curly’s Wife). The characters are “real” because we suspend reality long enough to embrace the fiction. Ethnographers and UX researchers do the same: suspending surface stereotypes long enough to embrace a more complex reality after spending weeks/months in the field.

Both take a leap of faith — to start with something wishy washy and “fake”, stay curious, and keep digging for something more poignant and actionable. We create a generalization as a starting point for learning. Personas are helpful. Use them correctly and you will develop better products. Force them on teams — “inflict” them on teams, to quote an engineer — and you’ll erode trust, detach the team from the user/customer, and harm the end-product.

Whip-Cracking Personas

The worst abuse of personas is when they’re used to basically tell people what to build and who to build it for. They embody the why, who, what, and how without any room for exploration and disagreement. Any person in their right mind will start ignoring these and thumb their nose. In a retrospective an engineer once exclaimed:

You want me to spend the next three months of my life working on something for an imaginary person you dreamed up for the kick-off deck?

The rest of this post will assume that you’re intellectually honest and rigorous, and that you are open to engaging with your team to build a better product. If that’s not the case, then you’ll probably get bored.

Yes I’m Guessing

A great start is to eat the humble pie and openly acknowledge that you’re guessing. This seems trivial, but it might not be immediately clear to the team that you are consciously and intentionally “making believe”. These “[proto persona](https://uxmag.com/articles/using-proto-personas-for- executive-alignment)” (a first pass persona not based on validated assumptions) represents your best guess at the moment. The challenge of product development is to iteratively validate these “who” assumptions. Who is this fictional character? What job do they do? When we’re one-hundred pages into this book, what will we know?

How do you structure and visualize this approach? Instead of a static (and quickly stale) persona, we’d use a Kanban board (or “canvas”) to prioritize assumptions, and then plan and execute experiments.

The challenge here is that openly acknowledging how little we know is not exactly the stuff of CTO and VP of Product dreams. It makes people uneasy. Validated experiments don’t result in deployed 1s and 0s. Teams are frequently measured in terms of output, not outcomes. But if you foster a culture that is failure-safe and focused on learning you’ll be surprised by the engagement this inspires on the team.

If you’re going to make the persona (and your assumptions) visual, commit to keep iterating on the content as the team learns. A stale persona is worse than no persona at all.

“Real” People

Another approach — and one I’ve found very effective regardless of organization culture — is to focus on “real” people instead of generalizations. This is the persona gateway drug for the uninitiated. Knowing that this human actually exists in flesh and blood does wonders.

At first I was skeptical and braced for the valid “low N” argument (focusing on one person is the queen of small samples). In a fit of “ok, I’ll try personas one last time” I took pictures, video, and audio. I had the team design their own persona template based on a collection of real humans. Together we referred to the users by their actual names.

These “personas” — while not strict personas — came alive. Because they were actually alive. The team could jump on the phone and chat with them. What was impressive in this case was that the team had a much easier time moving from the specific to the general. They noticed commonalities. We developed generalized personas by going backwards — which essentially mimics how skilled designers and marketers create personas in the first place. It was a good example of experiencing the thinking process instead of mandating it.

Starting with Fake Fake People rarely gets you to Real Fake People

Salience

People can be extremely lazy with the types of media they use for personas. And designers are often the main culprit. They’ll create complex and beautiful persona templates while missing out on opportunities to use video, audio, and work product samples (e.g. spreadsheets, forms, plans, etc.) The templates are so rigid that any new learnings are impossible to incorporate. In short, they’re made for Show, and not Tell. Cute for portfolios, but not so helpful for teams.

In short, they’re made for Show, and not Tell. Cute for portfolios, but not so helpful for teams.

Let’s say you’ve interviewed ten people and you’re starting to find some commonality around the technology usage dimension. Consider editing down clips of video (or audio) for that dimension and splicing it back to back. This will drive home the point with more salience and impact. Most importantly you’re letting the team explore the connections instead of force-feeding your biased summary of findings. Work backwards from the specific to the general, not the other way around.

The granddaddy of persona fastracks is the “real world” customer visit. Rent a van and go. I’m amazed by how few product managers, let alone engineers, actually engage with their customers and users in their offices. Your precious UX breaks down with eleven open browser tabs, interruptions every three minutes, and a barking boss down the hall. No slick persona can replace this experience … especially second hand through a UX researcher or product manager proxy. Taking a full day off away from the screen might seem like a productivity killer. But so is building things people will never use.

In a pinch video can work too if your org is pushing back, or if visiting customers on site is impractical. At a former gig I filmed “confessional” style videos with twenty odd customers/users. I set the context and lowered the customer’s guard. No topics were off limits. The end result was “loved” by even the staunchest persona haters. It felt “real”. The same held true for monthly customer research panels where we invited customers to speak to a room of 15–30 engineers over lunch. Even the staunchest persona-loathers enjoyed these sessions (and the free lunch didn’t hurt).

Salience Part II: The Story

What excites people more: 1) knowing how old a person is and that they like puppies, or 2) knowing that a person saved a stray puppy from freezing water on the eve of their 30th birthday during a freak ice-storm in Wisconsin?

Check out the period table of storytelling and get lost for an afternoon.

Periodic Table of Storytelling

The summary and bullet-pointed nature of personas is the persona achilles heel. I remember interviewing a person who was caught in a terribly difficult financial situation. He was terrified that he would let his elderly mother down by mismanaging the property she had entrusted him to rent. Her care at the assisted living facility depended on it. Now that’s real. No bullet point can capture that. Playing the audio to the team captured it perfectly without any platitudes about empathy.

This is why personas should be used in conjunction with customer journey maps and other time-based visualizations and artifacts. Don’t feel limited by the format or template of the personas. Consider storyboards, picture montages, video montages, and more traditional journey maps.

Some of the caveats above still remain true. A “proto” customer journey map is still a hypothesis. Making it more visual doesn’t solve that problem. But by “working backwards” from qualitative research you can make this exercises pack a bigger punch.

Jobs To Be Done

Jobs-to-be-done is an interesting counterpoint to traditional personas and something I’ve seen resonate with product development teams. I’m not sure I’m a fan of doing away completely with personas, but I do think jobs-to-be-done makes a great case for focusing less on the classic product marketing wheelhouse of demographics and stateless, causality-lacking generalizations.

These attributes, generally in the form of demographics, do not bring a team closer to understanding a customer’s consumption, or non-consumption, of a product. The characteristics of a Persona (someone’s age, sex, race, and weekend habits) does not explain why they ate that Snickers bar; having 30 seconds to buy and eat something which will stave off hunger for 30 minutes does explain why. ([Intercom](https://blog.intercom.io/using-job-stories- design-features-ui-ux/))

With B2B you frequently encounter situations where you’ll have customer wear different hats depending on the size of the company. Users are grouped by needs and goals (both emotional and job-related). Imagine two CEOs, both with similar demographics. The president of a small company might wear “all of the hats”, while the CEO of a large company focuses on top-level decisions. The SMB president embodies many jobs-to-be-done, least of which is trying to manage the wrenching stress of overseeing a small business.

There is a subtle difference between

“This person is stressed. This person is overworked.”

and

“This person is hiring our product to reduce stress in their day and to work more efficiently.”

A big word of caution is to put too much emphasis on official roles prescribed in your product. What is an Administrator exactly? Are they all the same? Do all Read Only visitors have the same needs? Don’t create personas directly from your system-roles.

Relationships Matter: No Persona Is An Island

A major failing of traditional personas is that they fail to describe relationships. Relationships drive collaboration and interactions. Relationships create product challenges that extend beyond the singular wants, needs, and egos of individual people. And for the purpose of engaging teams understanding relationships drives empathy and novel solutions.

Let’s say you have a golfer and a caddie. What are the inputs and outputs of that relationship? The golfer is relying on the caddie for local knowledge and emotional support when she shanks the ball into another fairway. The caddie is relying on the golfer for money, for conversation (perhaps), and for regular work. Both have a relationship with the Pro and other Golfers.

The relationship view is a much needed layer of understanding. The real opportunities for products often exists along the edges … not at the nodes. Work passes between people, not inside the confines of single personas. A successful product addresses the needs of all parties. These diagrams don’t fit into the neat and tidy persona templates, but they express a more realistic set of assumptions.

The Why

Observing humans is one of the great catalysts for invention and innovation. It’s how you develop products that magically read the customer’s mind even if they’ve asked for something entirely different. You notice the subtleties. Your design decision batting average improves.

But as they stand personas have a bad rap. Framing personas merely on their capacity to drive empathy is too short sighted. And frankly it also feels elitist. It casts engineers as lacking empathy for users, when in fact they rightfully lack an appetite for shoddy assumptions.

There’s a couple reasons why “experienced” cross-functional teams perform better. The first is that they know when to trust and challenge their intuition. The second is that they know how to ask better questions and that staying curious is the key to the game. Third is that they combine techniques and have mastered the core skills (“just code and deliver” below). Personas, and their inherent ambiguity, definitely makes things more complicated at first …

Shu Ha Ri Kokoro — Allistair Cockburn

When working with an inexperienced team this can be a challenge for the UXer. You know that the persona process can yield better, leaner, more simple, and more effective product … but honestly it all feels a little hokey. Hopefully the advice above helps, and I’d love to connect to learn what has worked for you!

Don’t do personas for the heck of it. Build better products together.

The Iron Triangle Is Dead

Illusions of singular org culture, intervention, and the “right way”

The Iron Triangle Is Dead

Illusions of singular org culture, intervention, and the “right way”

There is something very calming about doodling in a notebook. For me, Saturday mornings is about doodles and coffee.

The [traditional Iron Triangle](http://www.projecttimes.com/articles /traditional-iron-triangle-vs.-agile-triangle.html) has three nodes: Scope, Resources, and Schedule. When you talk to executives they’ll describe their central challenges as Growth, or Innovation, or both. As product developers we’re supposed to decide between [Building The Right Thing, Build It Fast, and Build The Thing Right](http://yedingding.com/images/deliver-better- product-i/KnibergRoles.jpg?1404985052).

The reality is that there are far more things at play. Contrary to the simplifications, there are no levers … but rather fields, sinew, arcs, push, pull, momentum, complexity, and travel. Creativity is a journey. Scale has multiple roots. Quality doesn’t just magically materialize.

This is what I came up with (click here for high res). What do you see?

Focus Until It Hurts

To startup founders and early team members, focus can be extremely uncomfortable. It defies many of our intuitions about customer…

Focus Until It Hurts

To startup founders and early team members, focus can be extremely uncomfortable. It defies many of our intuitions about customer-centricity, risk mitigation, “working hard”, and seizing opportunities. We are by definition opportunists and risk-takers and the list of good ideas is endless.

It’s easy to talk about focus. But much harder to BE focused.

When the lights go up …. think of all the great things we could do!

It occurred to me the other day that what we call “focus” is often way too comfortable. It’s a bandaid on the fleshwound. We resort to familiar thought patterns and fixes:

Our meetings need to be more efficient! No meetings!
We need better tools!
We need to improve our ability to communicate!
We need better processes! We need more accountability!
We need rules around emailing, chatting, and documentation!
We need more resources!
We need to be more efficient!
We need to protect people from distractions!
We need to do more planning upfront!

This is not real focus. These things address the symptoms of poor focus, not focus itself.

Enter the dichotomy. For the doers and those on the front-lines, real focus feels amazing. You’re in the zone, making quick decisions, and building and selling things customers love.

For managers, leaders, and other anointed decision-makers real focus can feel extremely painful and counterintuitive. You have to push yourself far beyond the point of comfort just to defeat your tendencies to chase waterfalls. It should feel very uncomfortable and awkward.

So what does real focus feel like? How do we know? My suggestion is to look carefully at the team and look for evidence. A focused team …

Is Safe. Their experiments are safe to fail and individuals are free from intimidation, harassment, and discrimination. The environment supports a growth mindset and is supportive of different learning and communication styles. (See Anzeneering by Joshua Kerievsky)
**Has Congruency. **There are no backchannels and scuttlebutt. Bad behavior is not tolerated for political reasons. The team shares a common reality — not by force or command, but because they share a common mission and narrow focus. When a conversation involves three people … then those three people are present and involved.
Says No Often: no to meetings, no to prospects, no to partnerships, no to new tools, no to process, no to feature requests, no to customers, and no to second choice candidates. They say no so often that they end up saying it less. This isn’t a top-down No — the manager playing wackamole in a desperate attempt at control — but rather a whole-team habit.
Says Yes Quickly. Yes means Yes, not Maybe. Individual team members can make consistently good decisions without asking for permission, navigating politics, or needing “buy-in”. No one person owns the Yes, because with crisp focus anyone can say Yes confidently.
Communicates Openly and Respectfully. They’re able to “get real” and speak candidly. When it doubt they meet in person and resolve differences. Focused teams also spend a lot more time talking about what they’re actually DOING — the work and what it takes to get it done — than about wishy washy future plans and ideas.
**Has Fewer Constraints. **Humans are terrible at juggling “yeah but”s and “but we have to consider”s. When you add constraints you increase complexity and in turn decrease the chance of getting anything meaningful done.
**Works Less But Deliver Better Outcomes. **They exhibit an almost boring level of productivity. Stuff just “gets done” without a lot of heat and drama. But output isn’t the end goal. That output results in better outcomes for customers, co-workers, partners, etc.
Feels Flow. Distractions fade without command-and-control or efforts to promote “efficiency, accountability, and velocity”. They exude focus and a calm energy. Work is challenging, engaging, and energizing.

Instead of trying to control culture, look for these characteristics to nudge things in the right direction. Challenge your own intuitions about what focus looks/feels like, and regularly engage the team in assessing the current level of focus. Push yourself to the limit — far beyond being “a little uncomfortable” to the point of being ruthlessly focused — and stay the course.

To Experiment Is Human. Reality is a **cker. And The Law Of Two Feet

Topics: Lean Startup, Millennials, Design Thinking, Cheap Vodka, Intuit, Craft, and Call To Arms

To Experiment Is Human. Reality is a **cker. And The Law Of Two Feet

Topics: Lean Startup, Millennials, Design Thinking, Cheap Vodka, Intuit,

Craft, and Call To Arms

Spend time with most product development teams these days and you are likely to hear a lot of talk about assumptions, hypotheses, experiments, validation, and “tests”. The[ Lean Startup glossary](http://venturenotebook.com/post/lean- startup-terminology) permeates mainstream startup coffee urn chit-chat, standups, and pitch decks. [Canvasses](http://www.lean-startup-coaching.com /wp-content/uploads/2013/06/lean_canvas_visual_management.jpg) adorn hallway walls. The A/B tests are humming! The spin-offs like LeanUX are doing great. All hail intellectual rigor and the scientific method!

Reddit flash. Reality is a **cker.

Yes … liberté, égalité, fraternité: the experimentation Force is strong. Experimentation and learning is hip and cool and the millennials dig it. It’s like college or grad school never ended. You can work at a disruptive digital widgeteer and continue to be creative, rigorous, and true to yourself. Battle- weary forty-somethings like me dig it also because it lets me take my work to a more impactful, and more challenging place. It promises fewer [HIPPOs](http://www.forbes.com/sites/derosetichy/2013/04/15/what-happens- when-a-hippo-runs-your-company/#51893ce24847) (highest paid person’s opinions), more craft, more honesty, less politics, and less bullshit.

This stuff is a dream come true for the doers, crafters, and renaissance millennials. It jumps off the shelves.

Unfortunately, the Koolaid is spiked with some [wicked cheap vodka](http://gizmodo.com/5966569/why-cheap-booze-makes-your-hangover-so- horrible).

Most organizations are structurally and culturally incapable of making it safe for teams to experiment and occasionally fail. As companies progress out of the do-or-die Act 1 of their trajectory, their once open attitude to experimentation shifts to a messy balancing act: making teams believe they’re empowered to solve problems (heck, it is great marketing and keeps the foosball table humming), while at the same time executing on the assumptions and guesses of anointed deciders.

Noise overwhelms signal, opinion overwhelms evidence, and the quest for output overwhelms the quest for validated outcomes. What a terrible vodka hangover. And that’s only the start …

Organizational fascia restricts movement and innovation, alignment deteriorates, the pressure increases, the perceived need for control increases, processes multiply, and the cycle reinforces itself (gotta love complex systems). Experimentation and learning become afterthoughts. And then the company accu-hires an innovation lab and starts doing hack days, longing for its innocent childhood, skinned knees, bruises, and bright smiles (and all).

http://blog.nwf.org/2013/06/how-to-get-dirty-for-international-mud-day/

Meanwhile, the most talented people without stock options have hit the road (otherwise known affectionately as the “[law of two feet](https://opensource.com/business/10/8/darwin-meets-dilbert-applying-law- two-feet-your-next-meeting)”). The former trailblazer wanders drunkenly into oblivion, talking about the good old days, and then joins the board of a startup.

<http://tokyomango.com/tokyo_mango/2011/06/photographer-documents-drunk- salarymen-passed-out-on-sidewalks.html>

Craig Larmen (of LeSS fame) scared the crap out of me at an Agile meetup in 2015. I asked him about “bottom up” change and he flatly explained that doing change “halfway” is worse than no change at all. In short, making people see the forest through the trees while cutting the forest down is worse than no change at all. You incite the inherent tendency of the masses to embrace impactful and honest work, while not being able to dislodge the leadership hegemony. That was a buzzkill, but I couldn’t completely discount his argument.

http://www.marinephotobank.org/resources/OIFcontestwinners2012_essays_Potenski.php

This is the let down oft reported by millennials after joining vibrant startups only to have the magic carpet pulled out from under them. And also experienced folks after realizing that some organizational-viruses never die. There has to be a better way, no?

This stuff is hard. It’s not a game of lip-service.

Read Suzanne Pelican’s piece Design thinking in the corporate DNA to understand the gumption required for deep structural change (at Intuit). Note also that the initiative had deep roots in CEO [Scott Cook’s commitment](https://hbr.org/2015/01/intuits-ceo-on-building-a-design-driven- company) to “be considered one of the most design-driven companies in the world” by 2020. Pelican’s mention of Eric Reiss isn’t a namecheck. Intuit doesn’t phone in its commitment to a more intellectually honest and rigorous approach. They live and breath it (for now). Pelican writes:

A common trap for us is to take something in its infancy and try to scale it big. Build it. Launch it. Move on. Well, it doesn’t work like that. Remember how long it took before you mastered design thinking? This isn’t something that you have people try once and then expect them to get it. It takes about six to 10 experiential, immersive, contextually relevant experiences before someone finally “gets” it and can make it their own. Eight years later, we’re still building this skill into our employees, one experience at a time.

Contrast that with the rigor most companies put into their experiments, canvasses, validation, and evidence-based approaches. When they hit the inevitable letdown, they blame the tools and methods. Mistake!

Evidence-based approaches aren’t the problem. Lean Startup combines a number of tested methodologies. Design thinking is a solid and very time-tested problem solving approach. [BML](http://steveblank.com/2015/05/06/build- measure-learn-throw-things-against-the-wall-and-see-if-they-work/), the double-diamond, [PDCA](http://asq.org/learn-about-quality/project-planning-tools/overview /pdca-cycle.html) … while subtly different, would be grouped by visiting aliens all under the same category, and categorize them as “more functional”. They are innately human.

We’re inundated with ways — under “ideal” circumstances — to build great products people love. My Twitter feed swims in it. The summary is basically … “I WISH I could spend my day working like this!” These methods are humane, rigorous, curious, and failure safe.

And then you have the whole host of “cultural change” articles that explain how to hack organizations to make them safer for things that work to work. We all seemingly want the same thing, while the “real world” folks are drawing gantt charts, setting KPIs, and selling stuff people don’t use.

What’s the point? I want to encourage crafters (buzzy, yes), hackers, “makers” (buzzy, yes), designers, creatives, builders, and engineers to approach their work with passion, rigor, and curiosity. To seek out places where you are safe, and while those places are safe to build stuff that both excites you and benefits people. Use the law of two feet to live passionately and move where you find value. Promote a diversity-friendly, learning-safe, and failure-safe mindset, and work to create those environments for other people. Growth does not always imply sacrifice … if you stick stubbornly to your values anything is possible. Basically … don’t give up!

Show empathy NOT indifference
Ask why and who NOT how and what
Serve teams NOT agendas
Be guided by principles NOT plans
Be a team-member NOT a team-driver
Focus on challenges and needs NOT titles
Treat teammates like creative makers NOT resources
Provide context and data NOT solutions and platitudes
Have suggestions and opinions NOT demands and fiats
Be curious and open NOT dismissive and stubborn
Harness diversity NOT conformity
Embrace simplicity NOT oversimplification
Deliver outcomes and impact NOT features and output
Build less NOT more
Be transparent NOT opaque or manipulative
Be accessible NOT elusive or overbearing

Agreed. From a coach and humanist perspective.

Agreed. From a coach and humanist perspective. Exposing the system to itself might not cure the system, but let people make appropriate choices?

How I Forced Myself To Eat Healthy Food (For 40 Days)

I write some long Medium posts. This isn’t one of them. I’ve been meaning to share a simple hack that has helped me get back on the healthy…

How I Forced Myself To Eat Healthy Food (For 40 Days)

I write some [long Medium posts](https://medium.com/@johnpcutler/to- experiment-is-human-reality-is-a-cker-and-the-law-of-two-feet- 639ade01396a#.79wai7rot). This isn’t one of them. I’ve been meaning to share a simple hack that has helped me get back on the healthy eating wagon.

Step 1

Buy gift cards from healthy lunch places (and breakfast if you tend to eat while on the go). My favorites while here in Raleigh, NC are Happy + Hale and [Joule](http://ac- restaurants.com/joule/).

Go big. Really big. Like $500 big:

Convert the money to pieces of plastic:

Step 2

Take photos of your gift cards. You’ll be super pissed if you lose your wallet along with $500 in healthy food.

Step 3

Eat the food. Why not? You’ve invested this much into eating healthy. You might as well. Each morning I get the Breakfast of Champions at Joule.

and for lunch, I have a salad and some protein from H+H.

http://www.movoto.com/blog/food/best-restaurants-in-raleigh-for-vegetarians/

That’s it. There is something about spending the money upfront that keeps you motivated (for some people).

Talking The Talk: 32 Conversation Prompts for Product Development Teams

Topics: Learning goals. Decisions. Collaboration. Data. Experimentation. Personal passions. And respect for diverse viewpoints.

Talking The Talk: 32 Conversation Prompts for Product Development Teams

Topics: Learning goals. Decisions. Collaboration. Data. Experimentation.

Personal passions. And respect for diverse viewpoints.

Arnold Lakhovsky, The Conversation (circa 1935)

I’ve noticed over the years that diverse teams that communicate clearly, honestly, and respectfully will always beat homogenous teams that struggle with a lack of focus, trust issues, and silencing minority viewpoints. We look for quick fixes — a new methodology, a new process, a new structure — when our biggest challenge is creating a safe environment for sharing diverse viewpoints. And then, literally, learning how to communicate in those settings. (I speak more about this in my post [To Experiment Is Human. Reality is a **cker. And The Law Of Two Feet](https://medium.com/@johnpcutler/to- experiment-is-human-reality-is-a-cker-and-the-law-of-two-feet- 639ade01396a#.nle0kxrjr))

What do high-performing product development teams sound like? What do they talk about? How do they stay so focused?

For a while now I’ve wanted to create a deck of cards teams could use to learn to communicate more effectively in software product development team settings. There is a lot of material out there to help teams collaborate and communicate more generally, but I wanted to focus in on common product development situations.

So here’s the first iteration …

Tips For Facilitators

Print the prompts and examples on card stock and make your own cards (much cheaper than Avery index card labels)
Create a safe space that is friendly to curiosity, passion, and empathy. Set the scene by reminding participants that there are no stupid answers
Scope the discussion. Pick a specific product development effort
Underscore that as a team you’re practicing patterns that can be applied in new settings. So there is a specific application — the effort at hand — and more general applications
Use the cards as you see fit: team members can pick from the top, work as groups on a set of cards, get dealt cards, “pass the trash” to get answers from other people, etc.

Tips For Team Members

Be specific whenever possible. Relate things to your observations, your experience, your perspectives, and your needs. Be in the present. Discuss the current situation and decisions at hand. Be honest with your intentions. Stay curious.

When in doubt, remember the STATE acronym (from [Crucial Conversations Tools for Talking When Stakes Are High](http://www.amazon.com/gp/product/B005K0AYH4/ref=dp-kindle- redirect?ie=UTF8&btkr=1)):

Share your facts
Tell your story
Ask for others’ paths
Talk tentatively
Encourage testing

The Prompts

And here they are … to be improved, but “in print”

I’m concerned that if we ________, we may miss the opportunity to ________.

Example: I’m concerned that if we spend too long deliberating over the behavior of the page filter, we may miss the opportunity to test early with customers.

To feel more confident about our decision to ________, I would like to observe ________

Example: To feel more confident about our decision to add steps to the workflow, I would like to observe more customers completing the existing workflow

My primary reason for advocating for ________ is that I care deeply about ________

Example: My primary reason for advocating for the enhanced error messaging is that I care deeply about the user experience, and preventing customer frustration

A missing voice here is the voice of ________. This will heavily impact** .** We should explore **** perspective

Example: A missing voice here is the voice of Roger from customer success. This will heavily impact** him and the customers he works with by saddling them with a difficult to use feature.** We should explore his perspective

I feel strongly that if we ________ it will negatively impact ________ by ________

Example: I feel strongly that if we release without IE support it will negatively impact our less technically savvy customers by introducing a painful user experience

In my opinion, learning more about** ________** would have the greatest impact on focusing the team

Example: In my opinion, learning more about** the customer mental model for organizing their scheduled meetings** would have the greatest impact on focusing the team

One way to test this “in the wild” (with live customers and their data) would be to ________. By capturing data on **________ **we could decide whether to ________.

Example: One way to test this “in the wild” (with live customers and their data) would be to create a feature toggle and show a small % of our customers the new functionality. By capturing data on column sorting behavior we could decide whether to optimize our queries.

Before adding ________ I’d like to learn more about ________ so that I can decide ________

Example: Before adding a new API endpoint I’d like to learn more about any potential customer security concerns so that I can decide whether to anonymize visitor data in the response

The most valuable learning we could take from this project and leverage in other areas of the product would be the fact that ________. An immediate application of that learning would be to ________.

Example: The most valuable learning we could take from this project and leverage in other areas of the product would be the fact that our users select system roles that are far out of alignment with their actual “real world” roles. An immediate application of that learning would be to try to survey our users to capture their “real world” roles.

A blindspot in our current understanding is whether . **To learn more about this we could ** and observe ________.

Example: A blindspot in our current understanding is whether **our customers really need XLS export instead of a simple CSV export. **To learn more about this we could add a dummy option for XLS export to the existing menu and observe how many people select it who previously were not using our CSV export option.

A signal that would serve as a leading indicator of success in this situation would be that we noticed ________. As things ramped up I’d expect to see ________, with data indicating a ________.

Example: A signal that would serve as a leading indicator of success in this situation would be that we noticed more users exploring and testing the new Appointments tab. As things ramped up I’d expect to see a small set of users adopt the auto-scheduler, with data indicating a shift of between 80–100% of their appointments away from manual scheduling.

In the past I have observed that ________. This impacts my current point of view on our decision to ________

Example: In the past I have observed that **our customers have very different behaviors when visiting our app from a mobile device **. This impacts my current point of view on our decision to expand the primary navigation with more items

At the end of the day, I’d really like to say that I ________. That’s the personal contribution I care most about. As a team, I’d hope we’d ________ with data showing ________.

Example: At the end of the day, I’d really like to say that I got the endless scroll working smoothly. That’s the personal contribution I care most about. As a team, I’d hope we’d make the whole feed experience more user-friendly with data showing increased repeat engagement.

The next important decision I need to make is to decide whether to ________, or to ________

Example: The next important decision I need to make is to decide whether to spend more time optimizing page load time, or to move on to refactoring the image resizing logic

I primarily want to contribute by ________. I’d prefer to be less involved with** ________**

Example: I primarily want to contribute by listening in on some customer interviews. I’d prefer to be less involved with** observing usability testing**

While I trust Amira to decide ________, I think that decision would benefit from us having more data about ________ because ________

Example: While I trust Amira to decide whether to continue iterating on the address book, I think that decision would benefit from us having more data about current usage among power users because power users have many more contacts

I could contribute more if I understood exactly why ________ are advocating for ________

Example: I could contribute more if I understood exactly why Dan and Trish are advocating for the inclusion of trial customers in the on-boarding experiment

From my perspective, the riskiest assumption we are making at the moment is ________. If we’re wrong, that will impact us by ________.

Example: From my perspective, the riskiest assumption we are making at the moment is that users will recommend the service so quickly. If we’re wrong, that will impact us by making it difficult to hit our user acquisition targets.

It feels as if the greatest tension here is between ________ and ________

Example: It feels as if the greatest tension here is between shipping early to meet the end of quarter sales objective and spending more time on enhancing the feature to please existing customers

The area we have the hardest time establishing a shared understanding around is whether our** ________** need to** ** in order for them to ****

Example: The area we have the hardest time establishing a shared understanding around is whether our** customers** need to** have access to the edit history** in order for them to find value in the proposed MVP

An example of something I care deeply about is ________. While I respect those that do care about ________, I don’t find myself caring as much about those things.

Example: An example of something I care deeply about is the extensibility of our code. While I respect those that do care about the use of micro- interactions and new UI patterns, I don’t find myself caring as much about those things.

By spending less time focusing on ________ and more time focusing on ________ I think we could ________

Example: By spending less time focusing on supporting different payment types and more time focusing on the speed of payment processing I think we could improve the current user experience without adding undue complexity

I’d be comfortable having ________ decide ________ provided I could ________

Example: I’d be comfortable having Parrisa decide whether we switch reporting frameworks provided I could attend a meeting with the options clearly described including benefits and risks

With the support of the team, I’d like to spend some time exploring ________, so that we can better decide ________

Example: With the support of the team, I’d like to spend some time exploring how competitors have solved this problem, so that we can better decide how to add some low-hanging fruit differentiation

One way to get out of our own heads here would be to ________

Example: One way to get out of our own heads here would be to test the three options with customers at the conference tomorrow

Spending too much time on ________, and not enough time ________, might result in us ________

Example: Spending too much time on refining the information architecture of the dashboard, and not enough time improving the dashboard widgets, might result in us failing to add real value with the new set of charts

I’d be confident that we were on track if I observed ________ within the next ________

Example: I’d be confident that we were on track if I observed a large increase in the use of account tagging functionality within the next two weeks

One decision we could safely defer now is ________. A decision we should make earlier rather than later is if we will ________.

Example: One decision we could safely defer now is whether we use a noSQL datastore. A decision we should make earlier rather than later is if we will support custom fields.

Playing devil’s advocate, I’m not sure we are taking ________ into consideration. A benefit of focusing there might be that we could avoid ________.

Example: Playing devil’s advocate, I’m not sure we are taking seasonal differences in feature usage into consideration. A benefit of focusing there might be that we could avoid making UI enhancements based solely on behavior at the end of Q4.

The personal experience that is most driving my intuition here is** ** with a ** in the ________ domain. My greatest learning from that prior experience was that we should consider ________**

Example: The personal experience that is most driving my intuition here is** the time I attempted to nudge users to use tags instead of folders** with a B2B SaaS product in the advertising domain. My greatest learning from that prior experience was that we should consider the mental models of our less tech-forward users

I would happily pay ________ right now if I could see more data about ________. This would help inform how ________

Example: I would happily pay $1000 right now if I could see more data about customer search behavior and its impact on time in-app. This would help inform how we might define success for this initiative. Are we trying to increase or decrease time in-app ?

Our most valuable learning to date is that ________ . We can leverage this learning now by ________

Example: Our most valuable learning to date is that customers rarely check their email for feature updates . We can leverage this learning now by trying some different ways to present update notifications in-app

Getting The All-Hands Right

Can you really run an effective all-hands meeting each week? Is it worth it?

Getting The All-Hands Right

Can you really run an effective all-hands meeting each week? Is it worth it?

I think so. Meetings don’t kill companies. Valueless meetings kill companies (and individual motivation). In 1999, what was Google thinking? Shouldn’t they have been working?

In this post I offer some tips for all-hands meetings. They’re biased to my experiences and personal viewpoints.

How Often?

I read [this answer on Quora](https://www.quora.com/In-startups-how-often- should-you-have-all-hands-team-meetings) that fired my spidey sense:

Meetings pull people off of **important tasks **and slow productivity. If people aren’t on the same page, I would look at project management and other management techniques being used in the organization and have team leaders convey important information. I would use the all hands meeting for only big things like a merger, change in benefits, serious HR issues.

Hmmm. Is productivity the goal? Or efficacy? What are these “management techniques”? Should “team leaders” be the sole conduits for “important information”. And imagine how cool that meeting will be when they announce the merger, change the benefits, or address the serious HR issues. Joy!

I’m not about to say that weekly meetings are must. That’s a big investment and something you need to work hard to make valuable. But I would suggest holding them MORE often than is immediately comfortable. Stick to your guns. They can be improved and be made more valuable. Here are some examples (and stories) of companies that hold weekly meetings:

Google (Alphabet): Weekly
Pardot: Weekly
Twitter: Weekly “Tea-Time”. Note the situation in this link:

Source

Be Proactive. Not Reactive

It’s painfully obvious when leaders are holding an all-hands to address rising discontent vs. holding to a cadence. If there is not enough regular “news”, then you’re likely not moving quickly enough or creating enough impact. Stick to a cadence and defend it. David Karp (Tumblr founder and CEO) was quoted as saying:

One of my biggest regrets is waiting until we were about 20 people to start holding regular weekly All Teams. Getting up there in front of so many people I adored was overwhelming, and my first attempt was hardly inspiring. I realized I could have had three years of practice, and a chance to work my way up to the big team, if I’d started earlier.

Don’t Micromanage The Message. Let It Emerge.

Myth, ritual, and narrative are incredibly powerful, but they are difficult to manufacture or fake. Ask carefully … what priorities are you truly embodying (and mythologizing) in your all-hands meetings? What is the story? What is the talk that is walked?

Executives often see all-hands meetings as “alignment builders”. The advice is to keep it “efficient”, stick to the agenda, and monitor every word to “stay on message”. To many employees this will come off as too slick and controlled. Let it be messy. Let it be unscripted. Tell the story. Connect. An “efficient” meeting message can be easily communicated by other means. But myths, ritual, and narratives can’t.

<http://ocw.mit.edu/courses/anthropology/21a-212-myth-ritual-and-symbolism- spring-2004/>

Engage Introverts (And Mere Mortals)

Only the most vocal people will speak up in front of the whole company. How do you engage the mere mortals and the introverts? Set up an anonymous “topic/question inbox” and always address one (or more) of these issues. Always. Make them public before the meeting. Relying on your direct reports to communicate back the water cooler talk is a risky proposition. Go straight to the source.

Skip Status-Checky Stuff

Don’t waste time communicating financials or dry progress-to-goal updates. This is far better communicated in a shared presentation or email. Or video. Those interested in the nuts and bolts will read on their own time. The time is too precious for relaying information that is equally comprehensible (or perhaps MORE comprehensible) in written form. Why isn’t this information simply available for all who care?

The risk of communicating this in meetings is that you’ll either oversimplify for the audience — missing valuable angles — or go over most people’s heads. Hit the key points and move on. Focus on the important variances.

Share The Stage

Let non-executives / non-managers speak for 40–60% of the time. They are your rockstars. This sends the right message. Inspiration can come from all areas of the company. I’ve seen UXers, Business Analysts, Marketers, Engineers, and Salespeople absolutely wow large companies. Consider that Google allocates 50% of all-hands time to QA.

Who will share the stage?

http://www.uxforthemasses.com/improve-ux-presentations/

No Tech Issues

Deal with technical issues when involving remote workers. Have a backup option. Test the equipment. Have an open chat. Use quality microphones. Get a good quality video camera. It all matters.

Record The Meeting

On any given day you’ll have team members sick, on the road, or otherwise unavailable. You might also have virtual employees in a different timezone. Don’t leave them out. A side benefit is that you can go back and critique how the meeting flowed. To engage their remote employees and leave them feeling like part of the team, HelpScout replaced their all-hands with a video update.

Share Wins, Losses, and Learnings

It is incredibly important to make vulnerability, failure, and learning from your mistakes “safe” in your organization. Doing so in public sends a strong message, especially if leaders address their own missteps. Vulnerability (and humor) brings people together.At Etsy, [all-hands meetings begin with an opening talent act by an employee](http://www.businessinsider.com/how-etsy- does-all-hands-meetings-2015-6). That’s a sign of a safe environment. Information should move both ways.

General Stanley McChrystal (leader of the Joint Special Operations Task Force from to 2003 until 2008) was known to run inspiring DAILY huddles. How did he make those meetings valuable? An INC magazine describes his strategy:

By continuing to share his own news — good and bad — and being nonjudgmental toward the other brave sharers. He also made the meetings as fast — and filled with can’t-miss discussions — as they could possibly be. If a particular individual had a four-minute speaking slot, the “update” portion of his slot was limited to the first minute. The rest was open-ended dialogue, which Silverman says helped “in creating a shared consciousness.” That is, the units began to learn more about how their own projects fit in with the whole. Moreover, the updates had to be about the present day. “No one wanted to hear what you’d done in the last war,” the co-authors write.

Make The Meeting Optional

There should be no stigma around missing the all-hands. Some people simply don’t care. Meetings just aren’t their thing. Others have lost interest. And that’s a valuable data point.

Return To Past Issues

Have teams “groom” a small set of initiatives that deserve a regular update. Keep this list fluid and relevant. But return to old topics to provide an update. One common complaint about all-hands is that they aren’t “two way” and don’t answer prior questions. If you mention a projection in an earlier meeting, make sure to close the loop. This gives an expectation of continuitity. Topics come full circle.

Mind The Timing

Monday’s tend to drag. Teams are not in the right headspace to tackle a lengthy meeting with a big workweek ahead of them. Mornings beat sleepy afternoons. Friday afternoons are a wash. “Branch day” can cause major distractions for dev teams. You’ll never find the perfect time, but there are terrible times. Avoid them.

https://www.tumblr.com/tagged/ahotbrewwillseeyouthrough

Meeting, Measure, Learn

Typical negative responses to all-hands meetings include “too frequent”, “not relevant”, “no new information, and “boring”. This is vague and hard to quantify. Instead, send out regular anonymous surveys regarding the all-hands meeting and monitor trends in those results. The kneejerk response to these surveys is to make the meetings less frequent. Instead, consider sharing meeting feedback at a subsequent all-hands and take steps to adapt and experiment.

What has worked for you? When a frequent all-hands meetings not a good idea? What do you do if the meetings simply don’t drive value?

A Better Roadmap | Mind-Map | Mousetrap

This post is a summary of this video on YouTube. Check it out!

A Better Roadmap | Mind-Map | Mousetrap

This post is a summary of [this video on

YouTube](https://www.youtube.com/watch?v=H8Xlrd2QGmU&feature=youtu.be). Check it out!

Hint: Open in YouTube for a larger HD view.

Have you ever heard (or said) the following:

“I don’t understand the big picture!”

“I don’t understand how my work fits into the big picture!”

“We are working in opposition to each other. We need better alignment”

We know the standard solutions. How about a better roadmap? Or a list of major goals? Or another company all-hands? Or a new mousetrap?

The Problem

Strategy/roadmaps overviews:

rarely explain rationale
differentiate assumptions and facts, or degrees of certainty
fail to explain causality, and linkages
fail to link tactics and strategy

They tend to read like a list of to-dos.

Things slip. Despite our best efforts it is difficult to understand the “big picture”. The strategy lacks coherence. We slip into the weeds of horse-trading pet solutions and the “why” is quickly forgotten. This in turn saps creativity and focus, as teams clash and generate noise. Most insidiously, it becomes nearly impossible to understand the root assumptions behind high level goals and individual interpretations. Shared understanding is never captured adequately. Laying it all against a calendar doesn’t help. Reviewing it doesn’t help.

The (Proposed) Solution

In this post I’ll present a mind-mapping method to create that shared understanding. While technically it is pretty simple, this level of transparency can be challenging. It isn’t for everyone. But if you push through, you’ll end up with a far richer understanding of what underpins the roadmap or strategy. Why does this approach work?

It provides an “audit” of our reasoning
It explains our logic, assumptions, and data
It can be viewed at multiple “resolutions” for clarity
It “nests” well … the form can be nested inside itself

The Basics

Most goals have a “why”, some constraints, and some proposed solutions. I call these Because, While/Without, and By. We’ll repeat these throughout the mind- map.

Goals, Because (Why), While/Without, and By

An Example

I’m short on cash and my friend is coming to town tomorrow.

Because

I need to make $70 by tomorrow evening so I can take my visiting friend Bill out to dinner. This is my “why”. We use “because” as it helps us form coherent sentences inside the mind-map.

We specify a Because

While / Without

These are not solutions, but they guide our selection of a solution. We use “without” when we assume or know we don’t want to (or can’t) do something. We use “while” when we assume or know that we will do something alongside the solution. Here I list some potential constraints:

We list our constraints

While / Without Because

Each of these constraints has an underlying assumption. We make sure to differentiate between things we know, and things we assume. For example, I can’t do physical labor because I **know **I hurt my back. I assume travel could be expensive (or too time consuming), but who knows … maybe a friend will give me a ride. We specify these using the following format:

Each of these constraints has their own assumptions

By

Now that we have a clear understanding of the why and constraints, we dream up some potential solutions. We could start a lemonade stand, do some freelance web work, or borrow the money.

Potential solutions

Lemonade Stand is looking like a good option. I repeat our Because / While- Without / By form for this solution.

Because and While/Without

The forecast says it will be hot tomorrow. And I’d like to avoid using powdered lemonade … first because I hate the taste myself, and second because I assume people will feel cheated. Again I start with Because and While/Without. I hate the taste of powdered lemonade (and I think it will leave customers bummed) so I make sure to specify that:

It looks like the weather will be hot. And I hate the taste of powdered lemonade

By and By ___ Because

Our “solution” also has solution details, and these have underpinning assumptions. In this case I’ve made an assumption about what I can charge, my overhead, my location, and my product (fresh squeezed lemonade). My assumption is that $1 will hit the sweetspot.

Our solutions ALSO have underlying assumptions

Overview

Here is the completed mind-map for my goal of making $70 today. This could be easily handed to someone and the story would be told.

Going from a goal of making $70 to the details of the lemonade stand

Real-World Example

This can be applied to many types of business (and general problem solving) situations:

Take a SaaS company hoping to hit an ARR (annual recurring revenue) goal. Because sale’s goals are finicky and potential disruptive, we balance the goal with constraints. In this example we make sure to point out that we don’t want to sacrifice employee morale, or to stop innovating.

Sales Goals are potentially dangerous unless mitigated

We add assumptions to those constraints. In this case the sales goal is offset by a limit on the acceptable level of professional services income, first because it might distract the team, and second because it could sap employee morale.

Turns out that some revenue isn’t investor friendly

We add other constraints including employee morale, continuing innovation, and the all important churn/renewal goal (to offset overly ambitious sales tactics). And then we proceed to list solutions. We start with Sales and Marketing, but would eventually list product initiatives.

With the constraints listed, we move on to the proposed solutions

And that’s that. It isn’t complicated … but it requires patience and conversation. Using this format can help a team battle voids in shared understanding and come up with something that is coherent and actionable.

Please let me know if this works for you!

Team Health: A Daily Checkup

I hear people talking all the time about “measuring” product development teams. Do we measure velocity, value delivered, or bugs removed …

Team Health: A Daily Checkup

I hear people talking all the time about “measuring” product development teams. Do we measure velocity, value delivered, or bugs removed / introduced? But what if you flipped the script? What if teams devised their own daily check-in to gauge their performance? What if they focused on great leading indicators of success and health, and used those measures to guide continuous improvement efforts?

I think you’d see something very different emerge. As individuals we care for our health. As teams we should do the same.

Here’s a simple model for a daily check-in. [I’ve created a spreadsheet version in Google Sheets](https://docs.google.com/spreadsheets/d/1hUet- D9RLR7ctg6-KW9SNNrYRbL5-zYwt9eCYxLbokE/edit?usp=sharing). Feel free to make a copy of it and use as you see fit.

Find this spreadsheet [here](https://docs.google.com/spreadsheets/d/1hUet- D9RLR7ctg6-KW9SNNrYRbL5-zYwt9eCYxLbokE/edit?usp=sharing)

I’ve included the questions below with some background. The spreadsheet has a simple weighted scoring system.

Today our team:

**Had two hours of uninterrupted time to work? **How can any team function if their time is being continuously interrupted? Before you know it the whole day has slipped away. Two hours is an ideal chunk of time. Hammering out two chunks of two hours each is a major accomplishment in a distraction-filled environment.

**Had a conversation with a customer (or group of customers) involving >1 member of your team? **Why silo the front-line from customers? It may seem more efficient to let people act as an interface. But in my experience that just encourages hoarding of data, and introduces signal loss as information is filtered through to the builders and makers. Regular contact with customers improves intuition and encourages empathy.

Discussed facts about customer needs, usage, etc.(vs. assumptions, guesses, predictions)? Are your meetings filled with guesses? Guesses are cheap. Shift the conversation to facts and data and meetings suddenly become a lot more productive (and even fun).

**Learned something new? **If the team is not learning — about customers, the domain, their technology, or themselves — then they’re slipping backwards. Learning new things is stimulating. It makes your current job worth it, and sends you packing if it isn’t happening.

Applied a recent learning? To hone a skill you must apply it. Did you apply a recent learning today? Not something you learned in high school — that’s cool too — but something you learned in the last couple weeks.

**Had an energetic / whole-team discussion about something related to work (>10 minutes)? **We’ve all experienced those spontaneous conversations with our team. They aren’t forced. They need no official meeting to emerge. Everyone just spins around in their chair and starts having a good face-to-face conversation.

**Celebrated a win that resonated on a professional and personal level? **Most milestones don’t really resonate. A sense of impact is largely personal. How many team members experienced a win today?

Felt in the “zone”, a state of flow, challenged but effective? Flow is a great feeling. Time flies. The work is challenging but achievable. You don’t feel like you’re trashing. Anti-flow comes in many forms — negative dynamics, interruptions, lack of mission, and poor tooling. How many members of your team were in the “zone” today? In my experience this is contagious. When it’s “game on” everyone benefits.

**Participated in some kind of pairing activity? **Structured pairing can feel oppressive (especially if forced and mandated). But working alongside someone for some period of time can be a positive experience. Doing this cross-functionally (UX and engineering, for example) can yield awesome results.

Had an honest discussion about what has and what has not been working (>10 minutes)? Can the team “be real”. Did they get real? If so, this is a good sign. It is almost impossible to continuously improve if their is not a level of openness, trust, and safety.

**Made some sort of high leverage, reusable, accessible, and necessary contribution (internal facing)? **Not all work is customer facing. Sometimes we take the bull by the horns and improve an internal tool, or process. The work has a large benefit for the rest of the team.

Enjoyed a moment of brevity and humor, experienced by a majority of team members simultaneously? Have fun! The other day a joke on our team started on Slack and ended in a full team laugh. That’s powerful. If you can’t have fun together, it is unlikely you’ll be able to weather the dips of product development.

How would you adapt this list for your environment? Let me know if the comments below.

How To Tame Engineers, Be A Rockstar, and Ship ****ing Product

Introduction

How To Tame Engineers, Be A Rockstar, and Ship ****ing Product

Introduction

As product managers it is time we take a stand. Times are changing, and not in our favor. DevOps, UX, Agile, Design Thinking, Growth Hacking, Data Science … WTF? When did we lose our hold of the reigns? We need to fight back. We need to regain our honor. We need to ship ****ing product. And to do that we need to learn how to control engineers.

Tom Cruise as Frank T.J. Mackey in Magnolia

Engineers start their careers with a spark. They want to build things that make a difference. The problem is that their caring and passion causes a lot of problems. It slows us down. It makes being a manager of product, um, challenging. Is there an alternative?

Yes!

Our goal here is to have engineers care about engineering, but not get in our way. In other words, care enough to keep working very hard, but not to ask too many questions or push back. To be successful we want engineers to relish their craft, and to take pleasure delivering exactly what we want them to deliver.

I’m going to share a secret. Engineers have a defense mechanism. They like building things and they like writing code. Engineers can exist wonderfully without really having any say in the product. Things will be rough at first. They’ll huff and puff and complain about the product team, and then go home and pick out an outfit for Comic-Con. It will pass. And your agenda will remain unscathed. Why? Because they genuinely love what they do. How novel.

Yes. This is your Product School. Here are the keys to the kingdom. I feel almost dirty sharing these time-honored secrets. Learn the skills below and you’ll smash any desire to meddle.

You will ship ****ing product.

1. Master Of Ceremony

Conduct very elaborate ceremonies! Some teams have “sprint demos”. These are a perfect vehicle to exert your power and influence. Deliberate slowly as the team demos each feature. Really play up the fact that you’re the “approver”. Use this opportunity to make it uncomfortable for engineers who fall out of line. Relish in the approver role. Toss in a bit of discouragement here and there along with some barely believable encouragement. Remember, we’re trying to incubate productive apathy here folks.

2. International Woman Of Product Mystery

Let’s face it it. You spend a lot of your day in boring meetings. But why spill the beans? Add some mystery. Disappear into available conference rooms, cell-phone in hand. You have to cultivate a persona here, which means the no one wants to hear about you checking Facebook while you wait for GoToMeeting to load. Or giving status checks to people who can’t be bothered to read a tweet-length email update. No. You are an International Woman Of Product Mystery, and meetings are where the action really happens.

3. Own Your Stakeholders

Giving the team too much access to stakeholders is simply unacceptable. How will you ever cultivate your soft skills? You, and only you, “manage” the stakeholders. When it helps your cause — for example you want to impress a stakeholder with your smart engineer friends — then it is appropriate to mingle.

Invite stakeholders to the sprint demo as well. The key here is owning the channel. Protect it at all costs. One slick tip here is to constantly reiterate to the team how little these business types know about software development. Huff a little. Complain about marketing being marketing, and sales being sales. No one will want to deal with these folks after you are done. You will OWN the channel. I promise.

4. Pressure Applied Unevenly

Pressure should not work both ways. Take test-driven development. We ask engineers to test software, and make sure things work. This is binary. It works, or it doesn’t work. That rigor is uncomfortable, and not something we want to experience. That is their world, not your world. Features don’t tank. They “miss the mark”. Priorities shift because that’s how the world works, not because we were too busy fixing our Mac after we broke everything trying to install Python. We are the fortune tellers. We are the soothsayers. Our work does not “pass” or “fail”. Make this clear, and you’ll dash interest in our side of the house.

5. Own The Problem. Choose The Solution

“We own defining the problem!” By assigning yourself the noble task of defining the problem, you’ve basically written yourself a pass. Understanding the domain is our business. It’s our special skillset. The engineers are crafters and builders. They are the solvers (or at least they think so). Lucky for us it is possible to turn our pet solutions into problem definitions. We can tire the team out until they acknowledge our genius. The irony here is that we never really truly understand the problem to solve, and our solution often informs other problems. But that’s a detail. It’s too complicated. There are problem definers, and solution builders, and we know our destiny. Control both!

6. Hackdays. Mother Of Pragmatism

Hackdays are great for hiring videos and angst deflection. When people start giving you a hard time about your pet projects, make sure to remind them about the upcoming hackday. Hackdays signal innovation. And fun. And kegerators. And a sense of unbridled impact. But common sense says … every day can’t be like hackday because that would be anarchy! People would build things quickly and deliver them to customers within 5 days or 24hrs. PMs would be out of a job. Let hackday be your carrot. Dangle it. A couple cycles of the harsh comedown — that moment when you return from hackday to your unglamorous sales-driven feature request — and your engineers will be compliant.

7. Tamper With The Evidence

Censor all feedback that will invalidate your case. Crush it like Joe McCarthy. Scan that feedback and filter out all disconfirming data. We may live in a democracy, but since when is democracy transparent? Opacity is the goal. The project is airtight. Customers have been consulted. The stars have aligned. Our intuition reigns supreme. Please follow my lead.

8. They Call This “Experimentation”

Everyone wants to experiment! They experimented in the 60s. Engineers are science minded people. They love rigor. Use this to your advantage by suggesting that people do exactly what you want them to do as an experiment. Then don’t follow up on whether the experiment was successful or not. It’s awesome! You get what you want right away, but leave people a tad bitter about experimentation. They’ll withdraw back into their craft and code, leaving endless product management possibilities.

9. Voce del Cliente

Tout up models that cast product as the “voice of the customer”. Product people love people (of course). Engineers love machines. Engineers don’t really understand people, otherwise they wouldn’t be engineers. We love people. If we didn’t we could be engineers also. But we love people too much. Please, get with the stereotypes.

You want people to be a little scared of engineers. What would we do if we didn’t have product managers here to keep them building the right stuff? Remember that one time an engineer went rogue with a feature? Exactly. We run the risk of that happening at all times. It is a constant threat.

10. Flat Is Unfriendly. I’ll Have A Tall …

We want to play up politics in our organization. A flat company is unfriendly to product managers. What would we do all day if we weren’t playing telephone between all of these holders-of-stake? Sure we want a happy environment. That’s great. More work gets done. But we want to foster a glass ceiling of sorts. Engineers … resistance is futile. Don’t stress trying to rock the boat.

11. The Project Factory, Estimates, and Velocity

We need estimates even if those estimates are always wrong. When things take longer than expected we can always blame the team. Measure velocity as well! Because velocity is the only thing coming between you and your next killer release. The beauty here is that it all distracts people from measuring YOU!

Optimize your team 24–7. Push them to the brink of overutilization. Shift them off of efforts over and over again just to eek out every little moment of slack. If you do this enough they’ll just expect that you’re going to do that … and you’ll be able to pull them off of future projects at a moment’s notice.

Status checks make people feel like they are working on a factory line. And we like that. Because we value delivery. A well timed status check can sink hearts. But they’ll come around … because they’ll start playing the game as well! Remember, keep your eyes on the prize. Shipping ****ing product.

Work with UX to get things designed way in advance. That way you can show up the morning after a big push — when everyone is eager for the data, and to start iterating — and then announce the NEXT project. There’s no time for dawdling. Those Mocks need building. Someone has to get that work done! Announce confidently that the team is at risk of missing the “market window”. “We just have to execute!”

12. Data Is Not My Mistress (I Love PPT)

De-prioritize collecting data. Data has a tricky way of shining a light on what you’re doing, and we don’t want that. What you DO want is to selectively pick out the data points that let you do exactly what you want to do. Transparency is not the goal. Take control of the tools. Own the analytics software. Hold the keys. There is a major exception … at the end of a project when somehow you cherry pick a wonderful up-and-to-the-right chart for the board deck. Ride that freighttrain to a new job in biz-dev or market validation.

13. You Say Debt. I Say …

When teams talk about technical debt, usability debt, the national debt, the debt limit, debtors, or anything else debt-related make sure to look a bit distracted. Wax poetically about needing to pay the piper. And then pass the debt on to the next generation. Or throw them a bone and do a greenfield project until they get bored of that because DevOps is busy with the “main” environment.

14. MVPs

A great way to level set expectations with a team is to ship a super crappy feature that no one is excited about (known as the MVP). Promise that you’ll iterate on it, but don’t iterate on it. This is sneaky. Because on one hand the concept of an MVP — as an experiment, and a way to deliver an early hypothesis — is appealing to engineers. So you get their hopes up! But then dash them. “MVPs that get iterated on only happen in the movies”. We do real, pragmatic work here. Namely shipping what I want to ship.

15. Hard Skills Are For Folks On The Spectrum

Don’t pick up too many hard skills. Especially around data science or other things like that. Because then you’ll actually be needed by the team, and that will take up all of your time. The team will spend less time advancing your career. You want to be skilled in the things that engineers simply cannot do (because they’re too smart). What if an engineer hears someone talking bullshit? They might actually call them on it! Or playing the political game? No engineer will put up with that crap. Their loss, your GAIN!

16. Fan The Flames Of Dysfunction

The need for product management has a linear relationship with organizational dysfunction. As dysfunction increases, so too does the need for PMs. The greater the lack of focus, the more PMs you need. The more people distracting the product, and trying to do a million things at once … YUP!, the more PMs you need. You want a sea of competing priorities because only PMs can stir this unctuous soup.

17. Our Values Rock!

Tout organizational values that are extremely powerful and engaging. It’s great for hiring. And then transgress those values repeatedly. Play up the dichotomy. You might lose some folks in the process — even some of your best people (the 5–10% who really care about the mushy stuff) — but what you’ll be left with is a bunch of people who aren’t too bothered by the sappy stuff and/or can’t afford to hit the road. That’s perfect. By exploding their bubble of optimism and altruism you’ll be able to get down to business. We need to ship ****ing product.

18. Best Foot Forward

Structure your product team such that no one really feels empowered. They’re taking orders from the top anyway. This wears the engineers out and flushes any desire for direct impact. Alas, they’re just too distint from the center of decision making. Which in turn frees you up for world domination. Hire compliant PMs as well. You don’t want anyone going rogue and empowering their team as that will set a bad example for the rest of the organization.

19. Just Because…

Nothing puts an engineer in their place better than saying something vague like “it’s complicated”, or “it is a juggling act”, or “it was a tradeoff”. Even better is the phrase “just because”. That’s a great one. It really hammers home that there is this strange alternate reality where the best ideas don’t win, political clout is valued over intelligence and skills, and there is no proof in the pudding. Never mind that engineers make cost/benefit decisions every ten minutes. That’s too concrete for this discussion.

20. Master Of Meetings

It is very important to arrive at all team meetings five minutes late, and then to appear distracted, typing on your computer, answering emails, and partially listening to the team. UNTIL it comes time for estimates at which point you jump into action and pay rapt attention. Then run off very quickly because you’ve got another meeting. This is a surefire way to make sure no one wants any part of this PM business. They’ll leave that crap to you!

Another tactic is to always be running off to meetings where you’re going to decide the future of the team. Without them being there. Works every time.

Schedule meetings during your team’s most productive time. Overwhelm the team with meetings. Eventually someone like the CTO is going to say “we can’t have so many meetings”. Leaders will go off and espouse efficient meetings. How is this a benefit?

Firstly, you will not waste as much time with your team in meetings. They’ll build faster. You can spend more meetings advancing your career, and making plans without the team. People become so sick of meetings, that they’ll associate collaboration with meetings. YES! Success. We want them to hate meetings, put on their headphones, and work on what I tell them to work on.

21. A Big Batch Of Ship-ass

Remember, from a PM’s perspective you don’t really win from the little things. You win from the BIG things. Like Texas Big. You want to have a lot of fanfare around your releases. Don’t try these little itty/bitty improvements. No … take on big batches of work. It’s less work for you (less releases to manage). When things go sideways you can always blame the team, and then take credit for whipping things back into shape.

22. Scrum. Meet The Intern

Scrum is great because Scrum will make sure you need a whole lot of junior product “owners” if you plan to scale. You have all these teams and every team NEEDS a PO. By doing this you set low expectations. It’s not like you were planning to mentor them before throwing them to the wolves. Were you? Most definitely not, otherwise you would have given them two teams. Wait. You did. Any way … Your senior developers will suddenly look over and see someone a decade younger pinning stickies to the wall. It works like a charm. Even the crustiest hackers will crumble at this point. Doggedly they’ll announce “Just show me what you want to get built, and I’ll build it!” BINGO! We’re shipping ****ing product.

23. The Mystical Backlog / Roadmap

Be very mysterious about the product backlog. People shouldn’t be able to find it, and you should always say things like “we don’t like to plan more than a couple weeks out”. We all know you can’t trust adults to look at a list of things and understand that they might change. Change that backlog and you’ll have some seriously sad adults on your hands, who likely joined the company for its reputation for incredibly boring and predictable work.

This also goes for the product roadmap. “Roadmap” is a funny word. Suddenly the product team is a bunch of cartographers? Don’t be fooled, the “roadmap” is basically an artifact of yearly planning cycles. Someone “upstairs” has asked for a sense of what is going to get built. If you’re in the real world your industry is changing monthly, not annually. With some tactical wins here you’ll leave the team apathetic about anything that looks like a giant swimlane gantt chart. Perfect. The long view encourages long-term thinking. We hate that.

Conclusion

And there you have it. Your PM training in one blog post. Repeat after me …

I can ship ****ing product

We can take our nebulous, difficult to define, context-specific profession back. One set of dashed expectations at a time.

(P.S. … hopefully the satire was apparent :)

12 Core Competencies For Product Managers

Learn. Practice. Learn.

12 Core Competencies For Product Managers

Learn. Practice. Learn.

A college student asked me recently about product management and Product Management “skills”. I thought for a bit and sent her this list. The key here is that these skills can be learned and practiced. It isn’t magic. Other things must be learned the hard way.

I haven’t listed things like Agile, scrum, roadmaps, backlogs, user-story writing, etc. You can read a couple books and get the gist. Learning “Agile” in one organization might not help you in your next job. Learning to communicate clearly or facilitate a meeting effectively will serve you for your whole career (in product management, or otherwise).

And with that, a list of 12 core competencies for Product Managers:

Conduct effective customer/user interviews
Build revenue, pricing, and adoption models. Micro/macroeconomics
Experiment design and analysis. Statistics
Effective meeting design and facilitation
Mapping and understanding complex competitive, partner, and customer ecosystems. Complexity and systems thinking. Domain research
Basic data modeling, JSON, XML, working knowledge of relational and non-relational databases. SQL, REST APIs, processing data using Python, etc.
Experience with various analytics tools, and business intelligence tools. Know what you’re looking for, and where to find it.
Broad understanding of usability, usability testing, usability heuristics. Ability to communicate to the user experience team using a common language
Awareness of cognitive biases, and how they impact decision making.
Communication skills: listening, verbal, writing, and visual communication
Effective note-taking
Time-management

Any to add? Self-learning success stories?

What Startup Sales Can Learn From UX

Startups, Sales, UX, and building a repeatable growth engine

What Startup Sales Can Learn From UX

Startups, Sales, UX, and building a repeatable growth engine

As consumers and product users, we are perpetually purchasing “things” that end up going unused. We blame ourselves for misunderstanding our own needs and motivations, the product for not “working”, the salesperson for coercing us, and the flashy (but misleading) ad. For whatever reason, things don’t work out. Boxsets go unwatched, bikes go unridden, [high-tech car features go untouched](http://www.consumerreports.org/cro/cars/survey-shows-many-high- tech-car-features-go-unused), and personal finance software gathers virtual dust.

This extends to much of the software we [use in our day-to-day work](http://swreflections.blogspot.com/2013/11/applying-8020-rule-in- software.html).

For some hot domains in the B2B SaaS software world — collaboration, analytics, big-data, CRM, and marketing automation — the root problem is not a tool problem. Tools, and countless variations, exist by the boatload. Rather, the problem exists in our organizational cultures, structures, and roles, our data-literacy, our ability to adapt to new ways of working, and our innate individuality when it comes to interacting with products in general. It’s tough to be one-size-fits-all.

These are meaty problems that transcend domain. They attract a lot of entrepreneurial and investment attention, despite the competitive landscape and low odds of success. Even when you understand those root barriers to adoption (culture, skills, literacy), forging a repeatable business model can be challenging. But most don’t get that far …

Beyond dealing with the competition, startups routinely drift into confusion and cognitive bias. Founders confuse their own early sales efforts — selling on vision and big picture — [with the day-to-day work of their reps](http://www.bothsidesofthetable.com/2010/10/12/startup-sales-why-hiring- seasoned-reps-may-not-work/). We equate growth with demand and a large available market. And assume our product “fits” because someone presses Purchase Now or cuts a check.

Popular methodologies (e.g. Lean Startup) promote experimentation. But there’s a big difference between testing with a squirt gun and a firehose. Lean Startup stresses structured and focused experiments, but this rigor is often overlooked when the rubber hits the road and the team fires up Marketo and Salesforce.

Testing with a firehose can yield results (think growth and sales) but not the learnings required to sustain that growth before running out of money or imploding. This extends to being “customer-obsessed”.

We confuse our ability to sell to and support our customers with our ability to repeatedly make someone happy with our product. Heroic efforts feel great, but it is damn difficult to make them repeatedly great. It translates to customer education — “our customers would absolutely fall in love with our product if they knew how to use it”. And most nefariously to how we iterate on and build our product — “if our customers pay us, then their requests are valuable”.

The common theme here is a misunderstanding (either through lack of experience, or founder goggles) of something user experience professionals deal with every day. No one person or company thinks, works, and adopts software the same way. Personas are far more rich and varied than we would like to believe. Product complexity increases exponentially as the number of personas/goals/situations increase. To solve someone’s problem, and validate that you’ve solved it, you need to get [specific](http://www.instigatorblog.com/good- hypotheses/2011/05/05/).

This is something that most of us understand intuitively — “no one person is the same” — but its impact on product design and sales service design (sales is a “service” if you think about it) is routinely underestimated. It’s the opportunist in all of us. We’d like to believe that there is a homogenous groundswell of interest in our product. So we turn on the sales firehose.

Sales and UX have a lot in common. Both deal with psychology every day — sales to [close the deal](http://www.businessinsider.com/daniel-pink-to-sell-is- human-2013-1), and [UX to design the experience](https://uxmag.com/articles /the-psychologists-view-of-ux-design). Sales understands that certain pains are ubiquitous, and routinely exploits that to close a deal and connect that to the story of your product. It’s necessary to try novel things and be scrappy. New stories, incentives, and nudges move the needle in the short- term. What we say we need, and what we actually need are two different things. Sales and UX gets all of this.

Like users, sales teams optimize around what is “easiest” to sell, which may not correlate with what is easiest to support, retain, and grow. Internally, incentives reign supreme and — as any UX pro knows — it is difficult to reroute the sales freight train once it is up to full speed. Once a sales team gets moving it takes on a life of its own. Without [a strategy](https://hbr.org/2015/12/dont-turn-your-sales-team-loose- without-a-strategy), things can go a little haywire. Part and parcel to that strategy is having a sense of the “who”.

UX knows it is very difficult to design a product or service that pleases all people, in all situations. People may look similar, and their pains may, in fact, be similar, but their product needs are not similar. Sales sells to common pains. UX designs for specific groupings of people and their pains. When UX thinks about personas they consider (among other things) technical savvy, experience with similar tools, experience in the domain, psychographics, barriers to adoption, relationships, demographics, behavioral traits, and organizational culture. Importantly, they design for a limited “fingerprint” across these various dimensions.

http://www.elezea.com/2013/09/case-study-vumi-go-redesign/

For example, there is a big difference between someone who knows how to solve the problem (with the right tool) and someone who aspirationally seeks a solution. Both will buy the product and respond to pain selling. Building a product for both requires different strategies. John, an executive in a low growth industry working inside a stiff organizational culture will behave differently from Mary, an exec working inside a nimble, tech-forward organization in a high-growth sector. Both may be aware of the problem to solve. They agree on that. But John’s work will need to withstand organizational blockers, while Mary has to be scrappy and get the data she needs to secure next year’s budget.

http://www.bryaneisenberg.com/personas-magic-behind-mirror/

Increasing sales does not mean you have a [repeatable sales process](https://salesandmarketing.com/content/sales-playbooks-key-repeatable- sales-process), or a repeatable path to growth. It doesn’t prove your product actually delivers specific value. Proving this requires more rigor. You are validating a “designed” sales process:

A specific user persona, buyer personas, and organizational persona
Your ability to locate, attract, and communicate with all three in a repeatable fashion
Understand the varied needs of a specific set of users
Structured and consistent messaging and marketing … a singular brand message
Similar touch points along the customer journey
A match with the product as it exists today. Not an imaginary future version of the product
Acquisition and retention costs (including ad-hoc feature development costs) … focusing on ongoing expectations. A startup can rapidly meet new customer requests. Will the customer be as enthusiastic as that growth slows?

The key here is specificity. Selling to everyone may make your quota, but it diminishes learning.

UX deals with this often. When we research and design, we focus on specific personas (or small set of personas). When we test our designs, we focus on people AND situations that match those personas. We iterate on that understanding constantly. And then we apply those learnings and patterns elsewhere in the product. Through a variety of methods, UX Research seeks to answer three questions — [what do people want, what do people need, and can people use it](https://speakerdeck.com/tsharon/validating-assumptions-with-12 -ux-research-methods) — — through the lense of a specific person and situation

What are some specific examples?

Nothing new here, but UX (and marketing) develops AND validates rich personas. Are these people who we think they are? Does their behavior match who we think they are? We consider [psychographics, demographics, goals, motivations, roadblocks, domain-specific characteristics, current roadblocks](http://www.contentharmony.com/blog/bootstrapped-customer-persona- validation/), etc. This is commonplace for big companies, but during the startup phase we are constantly drilling down, iterating, and validating our “persona hypothesis”. This is almost impossible if you’re taking a broad approach. Sure, your sales and growth might be higher, but you’re not learning.

http://www.garymagnone.com/blog/content-marketing-digital-touchpoints/

This attention extends to the customer journey. How does the customer interact with your company from first impressions — the ad online or mention at a conference — to their first renewal as a happy company. UXers attempt to understand these types of problems using customer journey maps and then by validating these against actual customer behavior. Again, the more of these you now support, the more assumptions you have in “inventory”. Sheer luck and persistence can grow the business, but learning which journey actually produces that happy renewal is paramount.

Finally, UX is constantly testing prototypes. We design low-cost experiments (designs), test, and iterate. Before doubling down, we make sure the design is going to work. This extends to pushing product live and measuring how people actually use the product. Modern startup buzz-wordists have coined the term growth hacker, and on many levels UX and growth-hacking are remarkably similar: with common traits of creativity, experimentation, prototyping, empathy, data and analysis.

I’m persuaded that the real value of freemium and self-serve free-trial models is that they create a framework within which it is difficult to bias the results. The models limit touch points and user journeys. We validate our positioning, adoption, and renewal in a repeatable way that can be easily adapted. Perhaps that’s the true value … freemium and self-service free trials may not be “better” than more high touch sales, but they certainly have the potential to be a lot less biased.

In closing …

View sales as a service design concept, and embrace those methods accordingly. On principle, you’ll start with specific personas which is the real message here. You’ll learn to understand the customer journey across your product — from first touch to renewal.
Choose learning over growth. Learning starts with specific tests, not a firehose. Learning transcends departments in your growing startup. Set learning goals, not sales goals. The sales model validation process cannot be run independently of product or retention experiments.
Embrace the value of the lean canvas in all of its complexity. Don’t skimp on the market segmentation, cost model, and channel hypotheses. Testing more than one or two things at once is virtually impossible.
Attract a sales team that is open to iterating, learning, and rolling with changes in approach. Your best bet may be less experienced, but more flexible team members.

I would agree.

I would agree. Wrong choice of words on my part. I think I was probably thinking more of drivers and dependencies not “constraints” in the sense of resource constraints. I’d agree that funneling more resources behind a lack of focus can lead you even further astray (perhaps the hidden blessing of having a small team). I think it was Johanna Rothman who said something like a project with one driver and one major constraint can typically succeed. Two drivers and two constraints can succeed but only with great luck and oversight. And three driver efforts typically always fail.

Decision Making Transparency (The Why)

In the swirl of growth, it’s easy to confuse and conflate transparency on the decision making process, with transparency on actual…

Decision Making Transparency (The Why)

In the swirl of growth, it’s easy to confuse and conflate transparency on the decision making process, with transparency on actual decisions and details.

The Why is scalable because it carries the original intent of our decision, and not just the tactic.

Even in [radically transparent environments](https://www.sequoiacap.com/grove/posts/bzgw/radical- transparency) it can be difficult to consume all of the information peripheral to your day to day work. There is simply not enough time in the day. And the multi-tasking would kill you.

And then you have the information that is deemed too sensitive or distracting to share. Where to draw the line is outside the scope of this post, but suffice to say there are always pieces of information that are too sensitive or risky to share broadly.

The reality is that our work lives are largely influenced by external factors. Decisions driving team changes, promotions, strategic shifts, project choices, and tool choices can have a dramatic impact on the lives of the various stakeholders. In an ideal setting these decisions would all be “local”, but that is rarely the case.

In the swirl of growth, it’s easy to confuse and conflate transparency on the decision making process, with transparency on actual decisions and details. The former is powerful and engaging. The latter is so frequent that it’s impossible to keep up. But it is easy to conflate the two and assume that both are impossible.

It’s not impossible. Communicating the decision framework starts with some fundamental questions …

Who makes the decision? Who is impacted?
How is the decision currently made (factors, timing, process, etc.) ?
What are we attempting to maximize and minimize with our decision?
What is our path for continuous improvement with this decision making process?

The last two points are critical. We typically frame important decisions based on hierarchy … with the “decider” holding the power (and responsibility), and those impacted playing a receiving role. It is unidirectional.

Consider a different perspective …

Answering these questions takes work. But it scales remarkably well.

Those impacted by decisions are often the best to determine whether those decisions were effective. Did we realize the desired effect? How can the decision making process be improved in the future? This is the “Why” that people most crave. The Why is scalable because it carries the original intent of our decision, and not just the tactic.

When people advocate for transparency, what they typically care about is not knowing every detail. We quickly realize that’s impossible. But rather they care about understanding how and why the decisions are made, and how and why they can participate in iterating on the actual solution.

We trust others to make decisions. And they trust us to make decisions.

And then we enter into a partnership to continuously improve on those decisions.

It’s the combination — trust and collaboration — that turns the typical hierarchal decision making model into a partnership. And that lets information sharing scale.

Time Management: Tips for Product Managers

Time management can make or break your career as a product manager. You are never “done”. There’s always more to do than you can possibly…

Time Management: Tips for Product Managers

Time management can make or break your career as a product manager. You are never “done”. There’s always more to do than you can possibly fit into a 60hr week. And the cult of the rockstar PM only exacerbates the situation. Organizations are hesitant to split the role for fear of incurring coordination costs or losing that single “wringable neck”. It’s a recipe for burnout, and a big reason why people do their time in the PM ranks and then leave for greener pastures.

https://theconsultantlounge.com/2015/09/avoid-burnout-in-consulting/

Say No (Nicely)

It is very easy to get drawn into every single discussion, every single decision, and every single detail. PMs exist smack dab in the cracks of the organization. You** become** the information conduit, which is a blessing for your short term career, but a curse in disguise. No mortal can tie up all the loose ends, and you eventually end up pissing people off. So you’ll have to learn how to say No to meetings, calls, and continuous shoulder taps without being a jerk. Part of this is a mindset shift. Less savvy product managers tend to relish playing the information filter. But that simply doesn’t scale.

Shorter Recurring Meetings

Most meetings run too long. Ad hoc meetings lack focus, and rarely need to happen right away (and if they do, it’s usually a sign your organization lacks the ability to prioritize.).

Your best bet is to timebox a handful of recurring meetings (weekly, bi- weekly, perhaps) to deal with more “transactional” communication. A well run 20 minute meeting can trump a poorly run 2hr meeting. Use constraints to force focus. Instead of answering every single request from Sales adhoc, just schedule a 30m optional weekly touch base and Q&A. They’ll thank you eventually. This will leave more time for the open-ended / divergent brainstorming meetings that yield great breakthroughs and a happier team.

Organize Information (Quickly)

PMs spent an inordinate amount of time organizing and disseminating information. Most associate product managers get squashed under the load. Customer calls go undocumented, requests get lost, and meeting notes disappear into the ether — which in turn leaves people wondering what you do all day. If you fail in the central task of providing context to teams, you are essentially useless.

The trick here is to leverage all available tools. Find a good transcription service (I use rev.com). Record meetings. Use a tool like Evernote which features OCR, full-text search, tagging, integrations, and a solid API (see this great video by Aaron Walter on “Connected UX”). Put together an information radiator on a whiteboard. Most importantly, be disciplined and constantly iterate on how you provide context to your team. If no one is paying attention, find a better way.

Work Less and Time-Block

Product managers frequently operate under continuous stress, continuous sleep deprivation, and continuous work fatigue. This makes it difficult to be at the top of your game. Somehow you always seem to let tasks fill the available hours in the day. To combat this I suggest time-blocking (see the Pomodoro Technique) and calling a “hard stop” at a reasonable time each day. Look back on the last month of your work. Was all of that work really necessary? What work benefited the team?

High Leverage

What are your highest leverage activities as a product manager? Some examples:

Passing new data and context to your team is high leverage
Figuring out how to be optional and dispensable — not being the blocker
Being available to your team when they have questions
Sensing patterns, drawing together disparate sources of information
Untangling what stakeholders (including customers) say they want vs.what they really need

These are the things you should focus on. Going to a meeting where nothing gets done every week is not high leverage. High leverage work doesn’t necessarily need to be glamorous. A quick set of meeting notes summarizing a brainstorming session can move mountains. So be honest with yourself about what work actually moves the needle.

One of the highest leverage things you can do as a product manager is to figure out a way to build less, but still drive value for your customers. That takes time and it takes testing. It also takes a fair amount of relaxation and creativity on your part (see above). But the rewards are great. You can save the team weeks and weeks of work. And any time you can get some piece of software out there into the hands of customers earlier rather later is a huge deal. The highest leverage work gets straight to the crux of the problem … making valuable software.

Eat Lunch…

Eat lunch!
Use lunches for creative brainstorming with coworkers. Get outside. A change of scenery can often spark great ideas
Take breaks and exercise. You’ll be more effective when you are “on”
Know when you are at your best. Use that time for your highest leverage work.

Check out this classic HBR article: Manage Your Energy Not Your Time

In Closing

None of this is rocket-science. But as PMs we frequently get caught up in the day-to-day. Our work starts to feel 100% reactive. We lose, of course, but so does our team. Worst of all, it begins to promulgate the PM stereotype: overworked, narcissistic, controlling, untrusting, and fickle.

The goal isn’t to work 80hrs, but to discover those things that make everyone — and especially your team — more effective. Then, everyone wins — you, your team, your customer, and your business..

Your Startup: Food Truck or Buffet?

Is your startup a Food Truck or a Buffet?

Your Startup: Food Truck or Buffet?

Is your startup a Food Truck or a Buffet?

Food Trucks

Food trucks live and die by trying to do one thing well, and they’re relatively cheap to bootstrap ([$70,000 — $80,000](http://www.forbes.com/sites/investopedia/2012/09/27/the-cost-of- starting-a-food-truck/#440fea602930)). If your clientele dries up — the local venture funded startup goes caput, for example — you can drive somewhere else. It’s just you, your partner, your food, and your customers.

<http://www.post-gazette.com/life/dining/2015/07/26/Food-trucks-have-nowhere- to-go-but-up/stories/201507260052>

Food trucks let restaurateurs be creative and nimble. Writes Josh Ozersky in [Why Food Trucks Aren’t Going Away](http://ideas.time.com/2012/06/13/food- trucks-are-here-to-stay/):

You see, it’s not just diners who have become more fickle, more demanding, more impatient with the conventions of traditional restaurant food. It’s the chefs too, who want to be flexible, to try out crazy mash-ups, stunts, and culinary in-jokes

Of course food trucks [have their fair share of challenges](http://mobile- cuisine.com/business/why-do-food-truck-businesses-fail/) like licensing, undercapitalization, being myopic about your vision, the gold-rush mentality (sound familiar, startups), and lack of identity. And they can fail like any other business. [This article](http://www.huffingtonpost.com/2013/01/22/food- truck-failures_n_2499463.html) cites failure rates around 30–35%.

Buffets

People go to buffets to absolutely stuff their face. It’s [a sport.](http://midtownlunch.com/2007/03/07/the-ml-guide-to-all-you-can-eat- chinese-food-buffets/) It’s commodity eating. It’s almost sacrilegious (this Saudi cleric went as far as to issue [a fatwa against all you can eat buffets](http://www.huffingtonpost.com/2014/03/15/buffet-ban-fatwa-saudi- cleric_n_4971190.html)). The only thing “unique” about a particular buffet is its sheer enormity and the spectacle.

[Good buffets aren’t cheap](http://casinofabs.com/Controlling-Buffet- Costs.htm), with food costs in the 50–60% range and back of house costs much higher than traditional restaurants. You can’t start a buffet in a van. You need a cavernous kitchen, storage, ice for those massive bland Alaskan crab legs, big pots, and lots of labor. And that’s why most buffets feature mostly gut-filling, mediocre food.

Buffets are also [a food safety nightmare](http://www.foodsafetynews.com/2010/07/buffets-and-cross- contamination/#.VuZCBZMrKCQ) … even with the sneeze guards. Your Golden Corral chili [might have a rat head](http://www.nydailynews.com/news/national /florida-man-claims-golden-corral-chili-rat-head-article-1.1981988) swimming around in there if you aren’t careful (test first). It’s hard to keep track of all that food, rotate it, heat and cool it, and throw it out when it festers.

How About Your Startup?

Are you trying to be all things to all people, and suffer from quality issues? Do large swaths of your product go uneaten? Can you pivot and change direction easily? Is focus fleeting? Were you lured into the idea of offering a “platform”, but turned around to find that the broad offering was more of a collection of commodity-grade features?

If so, it might already be too late. Put on the brakes now. Figure out how you can stay food-truck-like for longer. Iterate on your product, and then take the step up to a “real” restaurant.

How Much Does A New Feature Cost?

More Than You Think …

How Much Does A New Feature Cost?

More Than You Think …

One of the fundamental challenges of product development is understanding the true cost of releasing a new feature. The benefits feel concrete. Shipping feels great. Talking costs is a downer.

Consider …

Opportunity costs across all disciplines
Cost to implement feature (engineering, UX, product)
Cost to implement incremental improvements (engineering, UX, product)
Cost to deliver feature (processing, storage, monitoring)
Cost to train people internally to sell the feature
Cost to train people internally to support the feature
Cost to market the feature to existing customers
Cost to market the feature to new customers
Coordination costs across all teams
Cost to document and train users/customers on new feature
Cost to maintain that extra documentation
Cost to train engineers on more complex codebase
Cost of slower engineering, caused by increased system complexity and maintenance
Cost to hire more resources to account for slower engineering
Cost of reduced flexibility, caused by increased system complexity and maintenance
Cost of maintaining system usability as system broadens
… until the feature reaches end-of-life (unless you retire it)

It turns out that engineering costs are but a small part of the puzzle.

Wow. So I guess it isn’t just a week or two of work! The good news is that you don’t need to cut a check for these things right away. The hard news is that you’ll end up paying in the long run. And many features end up going unused (or rarely used).

So … consider this expanded list of costs the next time you think about tacking on a new feature. Is it still worth it?

A SaaS Startup Cautionary Tale

A SaaS Startup Comedy. Sort of.

A SaaS Startup Cautionary Tale

A SaaS Startup Comedy. Sort of.

PDF version of mind map used in presentation

References:

YouTube Presentation (With Narration)

Prezi Presentation

Stop Setting Up Product Roadmaps To Fail

Why Read

Stop Setting Up Product Roadmaps To Fail

Why Read

Stop debating whether you are doing product roadmaps “right”, or whether roadmaps are evil. Look instead at the job you are hiring your roadmap to achieve. And then ask if the roadmap is the best tool for the job.

A Litany Of Roadmap Ills

Roadmaps are frequently abused. To save you thirty minutes, I’ve organized these observed problems into the list below.

Some of these problems are inherent to the process — you need to actively work to prevent them from happening. Others are caused by user error or deep organizational dysfunction. And some are governed by even broader effects like the planning fallacy, confirmation bias, and groupthink.

Roadmaps encourage people to…

Horse trade initiatives, placate stakeholders vs. focusing on value creation
Stick to the plan when the plan is no longer optimal
Chase harmfully high utilization rates (the jigsaw illusion)
Future sell, instead of relying on the current merits of product
Prioritize new feature development (items which can be easily understood and sold) over equally promising enhancements to the existing product
Converage prematurely on solutions
Rely on estimates, despite the fallibility of those estimates

“Big Batch” Planning

Roadmaps …

Encourage the illusion that efforts are linked to a timeline(when most aren’t)
Obscure underlying assumptions, rationale, and vision. Even when described (e.g. a theme), it is still difficult to parse why the theme matters
Institutionalize “big batch” yearly planning, which in turn decreases agility
Encourage group think — satisficing — over focus. Initiatives lose their bite
Fail to address the needs of all “users” (e.g. your roadmap is fine for communicating with executives, but fails to meet the needs of your front-line teams)
Discourage experimentation and acting on new insights / data
Create dependencies across the organization (decreases agility

This Tweet from Jeff Patton wraps it all up:

Some common pitfalls I described in a recent talk:

Challengers vs. Defenders

OK. That’s a pretty hairy list. I’m not the first to challenge roadmaps. Luckily this stuff is out there in the google-verse by the boatload. You will also find debates that look something like this:

**Challenger
**[Methodology] is flawed

**Defender
**You’re just not doing it right. The real value is in [Some Positive Aspect]. Yes, some people abuse these things. Just not me …
You need to get back to the basics …
You need to stop doing it the old way …

**Challenger
**What could you do such that [Some positive aspect] would be possible without the abuse, and observable negative effects?

**Defender
**This is heresy. Here in the real world we need [Methodology] because [Some Reason]. And plenty of great teams — you know [Company] — use them also. So you’re on crack!

**Challenger
**What is to say that [Company] isn’t successful in spite of [Methodology] ?

**Defender
**Damn you. I’m blocking you on Twitter.

Check out this overview of one of the classic Twitter debates (from a somewhat similar question … #noestimates)

If Things Were Awesome

To be clear, I advocate for thinking in terms of initiatives, problems to solve, and missions. And that’s nothing new or groundbreaking. I use mind maps like this:

This advice is mirrored by most of the roadmapping software vendors like ProductPlan and [Aha](http://www.aha.io/?utm_source=google&utm_medium=ppc&utm_campaign=brand_search&gclid =CJKj-bHg88sCFYMehgodOFoMzw), as well as folks like Melissa Perri, Roman Pichler, etc. All caution against using the roadmap as a glorified feature gantt chart.

The other day, Woody Zuill asked me something to the effect of:

what would need to happen such that this wasn’t even an issue. What would it take for the company to be awesome?

Let’s try that thought experiment …

What would a crazy successful and awesome product development team actually look like? Would they still have gant-like visuals for their roadmap?

Probably not. The future might look nothing like a 12 lane LA highway. Because you’d be on a bullet train.

Needs & Being Awesome

Continuing on that thought …

You’ve hired the roadmap because you have a Need
If things were Awesome, what would things look like?

Need: “The process helps us have the right conversations”
Awesome: “We have the right conversations without needing a prop. It is easy to get real, and discuss priorities without solutioning. We leverage the right decision making and focusing tools for the job, without bad side-effects.”

Need: “I need to know if you’re working on my favorite feature, or plan to”
Awesome: “The product development team continuously surprises and delivers value. So much so that pet features become far less important. We maintain a low planning-inventory. All team members are encouraged to submit ideas to solve our most important challenges.”

Need: “We have to meet to decide which features are most important, to advocate for our ideas, and favorite features”
Awesome: “The problem to solve is known, and all team members — down to the developers, UX, etc. — are empowered to solve them and try to push the needle without drowning in meetings. And we make continuous progress towards those goals. Everyone trusts each other. When we fail, that’s OK as well … provided we learn, and do better next time.”

Need: “We need to have a yearly plan, and the roadmap is part of that”
Awesome: “You always have focus, vision, and direction … not just in late December (or whenever your yearly planning period is). Gaining that shared understanding is a rapid process, and can happen at any appropriate time. Few dependencies hamper the team. We respond immediately to new opportunities, and data.”

Need: “We need to know what is coming down the pike!”
Awesome: “The product is sellable, awesome, and valuable as is. You’d be able to sell to those people without pitching shaky future promises. You’d discuss features released in the last two months, and the prospect would be wowed. From a technology standpoint we can flexibly tackle new challenges without a ton of notice.”

**Need: **“We need to see the big picture, where are we going, and how our work fits into that”
Awesome: “The evidence of impact is everywhere: in customer feedback, in the data, and in the dollars and cents. Teams link their work directly to a compelling vision (the big picture). Most importantly, the current work is impactful, so there is no need to future sell internally.”

Note: If you listen carefully, most “big picture” discussions are actually a code for “we don’t think we’re making a difference”.

<http://www.boost.co.nz/blog/wp-content/uploads/2014/03/Release-Planning-PSI- Program-Plan.png>

Need: “We need to coordinate with marketing, training, and support”
Awesome: “A steady stream of awesome. Short lead times are acceptable to partners, and the batches are small enough to handle gracefully. Teams iterate on features until they “hit the mark” and then marketing uses that actual data (and case studies and momentum) to market. Training and support coexist with the development teams instead of “tossing it over the wall”.”

Need: “The board keeps asking us for our roadmap”
Awesome: “The board knows what goals you are shooting for, and your progress towards those goals. Quarterly meetings involve real news, and real data, along with the sweeping vision (“we aim to take that hill, and that hill”). You’d exceed your goals, so no extra icing is necessary.”

No, no, no you’ll say. We need roadmaps to address these needs! But consider a time when your team was just flowing, building awesome stuff, making customers happy … was it because of your roadmap?

Conclusion

Roadmaps aren’t the problem, obviously. We pick our tools and methods. My goal with this post was to encourage you to challenge the “why”: why use roadmaps, why use roadmaps the way we typically use roadmaps, and what it might take to be awesome (such that this conversation is irrelevant).

Consider many of the enduring debates: estimates, roadmaps, technical debt, iteration length, team structure, roles, Agile …

Why do we continue arguing about them? Perhaps because they — and the methodologies we create to control them — are symptoms and medicine for those symptoms. Dig deeper!

The economic problem of (an organization) is rapid adaptation to changes in its particular circumstances. Then, the ultimate decisions must be left to the people who are familiar with these circumstances, who know directly of the relevant changes and of the resources available to meet them. This problem cannot be solved by first communicating all this knowledge to a central board which then issues its orders. But the “man on the spot” cannot decide solely on the basis of his limited but intimate knowledge of his immediate surroundings . There still remains the problem of communicating to him suchfurther information as he needs to fit his decisions into the whole pattern of changes of the larger ( organizational) system
Friedrich Hayek, Nobel Laureate in Economics

Opening Your Eyes to Real Customer Delight

Drawings by Claire Bowman

Opening Your Eyes to Real Customer Delight

Drawings by Claire Bowman

How delighted customers behave, and why measuring and learning from these

signals is likely one of the most important things you can do for your product

Yes … Delight

Rewind to a time before, [as Kevin Roose writes in New York Magazine](http://nymag.com/daily/intelligencer/2014/08/silicon-valley-whimsy- is-trumping-usefulness.html), “the titans of tech start[ed] talking like kindergarten teachers.” Delight meant a high degree of satisfaction … the 10 on a 1–10 custom satisfaction survey._ _Fast-forward and it has come to represent all that is wrong with gratuitous design-for-design’s-sake, startup founder- speak/gibberish, and hokey marketing campaigns.

Jared Spool beautifully describes the difference in this story about Hyatt Hotels and their “random acts of kindness” campaign:

The problem at the time, and the reason their customer satisfaction was going down, was that they had a lot of frustraters to combat. They were getting a large number of complaints. Instead of addressing those problems they decided to go for delight and focus on delighting people. [They thought] hopefully you can use delight to cover the bad smell of the failing hotel

That’s not the brand of delight I’m talking about in this post. I’d like to resurrect the classic, more general definition … because delighted means extremely satisfied or pleased. And this post is about what customers do when they are extremely satisfied or pleased.

Plus delight is 10 characters less than extremely satisfied. Onward …

The Product/Market Fitting Room

Start-ups constantly struggle with defining (and finding) product/market fit. They plumb product metrics hoping to “prove” engagement and [predict renewals](http://www.predictiveanalyticstoday.com/customer-churn-renew-upsell- cross-sell-software-tools/). From a strict dollars-and-cents standpoint, selling product and renewing customers is the goal. But, in most domains (and especially B2B SaaS), neither really indicates whether the customer is truly delighted with their purchase.

Many businesses make the mistake of assuming that a customer is loyal, simply because they aren’t complaining and they keep coming back month after month. -
[Wootric](http://blog.wootric.com/what-happens-when-you-confuse-repeat- business-with-customer-loyalty/), “What Happens When You Confuse Repeat Business with Customer Loyalty”

Users with a “meh” attitude toward the product often stick around — sometimes because they don’t have the time or energy to shop around, sometimes because they’re too embarrassed to admit to themselves that they purchased the wrong tool, and sometimes because someone is forcing them to use the software.

From “Meh” to “No, Thanks”

The trouble is that this customer indifference comes back to haunt you. That captive user leaves their company and becomes a buyer elsewhere. As your company grows, your time to sweet-talk individual customers into sticking around is reduced.

You start rationalizing by thinking that usability and delighting customers aren’t important in your domain, and that you’ll be fine as long as the economics look promising. Maybe you cobble together some white papers and share the occasional success story. Or, you fetishize using customer support, customer success, and [services](https://www.linkedin.com/pulse/consulting- organizations-vs-product-shanif-dhanani) to patch up holes in your product. Mediocre becomes the new normal.

This all takes a toll: your team eventually becomes disengaged. The product rots from the inside out. Turning back the clock and regaining your edge is a daunting task. You either start and stay there, or fight an uphill battle to find your lost (or maybe never explored) product mojo.

There is a way around this, but it requires stubbornness and bullheadedness: Demand to see evidence of real customer delight minus the Kool-Aid.

“Measure” and Observe Delight

I’m going to go out on a very un-data-nerd-like limb here. To truly delight your customers and create an amazing, differentiated product (and to do so consistently year after year), you’ll need to measure things a bit differently. I say this as someone who spends a great deal of time worrying about how to measure things and how to use descriptive, predictive, and prescriptive analytics to improve my product.

I’d argue that many of the product metrics we capture (e.g. engagement, conversions) are proxies for less tangible things like customer delight, advocacy, and product focus. The hard metrics can be used to predict churn and trial conversions, but they fail to cut at the central question: Is our product truly inspiring our customers and kicking ass? And, if so, why? Are we [In-N-Out Burger, or McDonalds](http://blogs.wsj.com/independentstreet/2009/01/28/in-n-out-burger- vs-mcdonalds-guess-who-won/)?

Consider an example: a not-too-impressed diner leaves a 15% tip. A drunk diner leaves a 20% tip. A thoroughly impressed and new fan-for-life diner leaves a 20% tip. All give the restaurant four stars in their online reviews. How do you differentiate rabid foodie fandom from “a decent meal” or a happy buzz?

Not-Too-Impressed, Drunk, or Fan?

You can do a sentiment analysis of the review. Factor in the tip. Record facial biometrics. Have the server assess the diner satisfaction. Measure length of the dining experience.

It is all “data,” albeit largely qualitative. The human computer is a pretty good pattern matcher and sensor (despite our various biases, or maybe because of them). [We lost at Go vs. Google](http://www.wired.com/2016/01/in-a-huge- breakthrough-googles-ai-beats-a-top-player-at-the-game-of-go/), but we are not half-bad at detecting rampant excitement. If it was all down to a perfect science, though, we’d consistently make great products, predict all trends, convert all customers, and never have product fails.

Why Measure/Look For Delight?

When we open our eyes to what customer delight looks and feels like, we get the right signals to tune our product strategy. By product here I’m talking about the the whole package: who you target, how you make customers successful ([customer success](https://medium.com/the-growth-hackers-cookbook/customer- success-has-a-quantifiable-impact-on-revenue-d18d25786863#.pkfvsojf0)), the goals and outcomes your software supports, your support team, and your sales team. From the service design perspective, every interaction you have with customers is “the product.” The customer experience extends far beyond logging into a tool each day.

The key is awareness and not rationalizing a tepid response. When you have that awareness of what a happy customer truly looks like, the rest becomes “easy” (but still damn hard). For the builders it becomes more fun and rewarding. And that has to count for something.

The Delighted Customer

So, what do you keep your eyes open for? Take a big step back from your dashboards, spreadsheets, and predictive algorithms and ask if your users/customers are truly delighted. Are they obsessed with your product? Do they self-identify with your mission? Are they your sales team, marketing department, and product idea box all wrapped into one? And not just one customer, or the occasional success story, but a good swath of your customers?

It is easy to pretend this stuff is happening. Or rationalize that it doesn’t matter. But when it really happens, it’s a awesome thing. If you pay attention, you may notice that the delighted customer…

1. Really Likes You

Bakes the team a cake. (This is not a joke — I’ve seen it happen!)
Visits you when they’re in town. Invites you out for drinks.
Remembers your name! And the names of your team members.
Bugs you for T-shirts. And then sends you a photo of them wearing the T-shirt.
Uses emoticons when writing otherwise dry emails. Like …

2. While in the Buying Process…

Seeks you out prior to purchase! Is delighted by what they imagine they can do with your product. Your marketing just gets them more excited. On that first call, is bubbling with ideas and questions before you even get started.
Shows hints of delight right from the start. Dives into a trial and take things further than you ever expected. On some level you feel like the roles have been reversed, and they’re selling to you!
Already knows how you compare to the competition — they’ve done their homework.
Can describe the precise pain they hope to address, or goal they hope to achieve, and connect that to unique product traits.
Makes the internal renewal case for you and spearheads the discussion with purchasing
Contacts you to renew, instead of waiting for your call. Contacts you to explore purchasing add-ons, instead of waiting for your email.
A couple of months after purchasing, writes to thank you. Literally, as in a handwritten thank-you note.

3. While Using the Product…

Describes your product as “very easy to use,” ”easy to learn,” ”user-friendly.” Cliche, yes, but NPS and SUS (system usability score) are related (more on this here). This you can measure quantitatively.
Uses your product/company name as a verb: “We ______ed it.”
Writes you unsolicited emails with feature/product ideas** (**not feature requests, or fixes for workarounds).
Sends you feedback on new features shortly after they are released, again, without prompting.
Invests money to integrate with your product. Many customers may ask for pre-built “connectors,” but the most passionate customers will find it worth it to shoulder the cost of integrating.
Does awesome and unexpected things with your product (things you never expected or planned for).

Hounds you to learn about the roadmap, not because they’re waiting on features, but rather because they want to plan their training and get the most out of new functionality.
Regularly seeks the help of your support team to resolve _their _challenges rather than challenges with your product. The difference is critical.

4. For Things They Value…

Writes or calls you to describe wins and provide proof (qualitative and quantitative data).
Describes how your product is actually changing the way they work and explains how.
Credits you for making their personal** **job easier and more effective. Or better yet, for helping them get a raise!
Proposes interesting partnerships if your products share a similar domain.
Creates their own training material around your product — not because your help docs aren’t comprehensive, but because they’re morphing their company around your product.

5. As an Advocate…

See this post [for more about the value of brand advocacy](https://medium.com /the-growth-hackers-cookbook/customer-success-has-a-quantifiable-impact-on- revenue-d18d25786863#.s6sz9843l).

Hounds you to be part of a beta group or research panel.
Refers you to friends and professional contacts in their industry.
Uses because when describing why they love your product: “I love ____ because.” Your best customer advocate is someone who can explain why the product benefits them.
Brings you with them to their next job, or at least tries.
Sends you unsolicited ideas for white papers and case studies. Volunteers because they want to be associated with the product. Provides you a reference logo for your website without prompting.
Interact with you across all available channels (blog post comments, forums, etc.).
Without coercion, recommends your product on sites like Quora, Stack Overflow, etc., and includes a detailed explanation of the “why.”
Hounds you about having a user conference, and maybe even offers to host one.
Promotes your product across their organization. Suddenly you get calls from people you’ve never met and they are already sold on the product because “_______ has been singing your praises.”

Conclusion

This is not an argument against being data-driven. Rather, it’s an argument for widening the information gathering net. I speak with many product teams. They describe the glory days of being able to talk to each customer, to fill their backlog with valuable items, and to ship software effortlessly. But now “things are complicated”, budgets are tighter, and there’s a pressure to show the ROI for product development efforts. Sure, build your analytics chops. Use whatever data — quantitative and qualitative — you can find. Predict, prescribe, and describe.

But don’t forget what got you here in the first place: happy, engaged, and yes _delighted _customers. Because in most cases the metrics will bring you back there anyway. Lay off the Koolaid and start listening.

10 Common PM Intuition Traps

Many situations in product development run counter to our intuitions. The nature of the work is constantly changing. Context morphs…

10 Common PM Intuition Traps

Many situations in product development run counter to our intuitions. The nature of the work is constantly changing. Context morphs frequently. Our teams, organizations, competitors, and industries represent a dizzyingly complex system. What we think works, makes sense and feels efficient betrays us.

The famous Katama weather rock …

Awareness helps. But so does habitually putting yourself in mildly uncomfortable situations. The quest for consistency and repeatability is often our Achilles’s heel and serves as a blocker to growth.

Below I’ve listed ten common intuition traps in product development. What resonates? Disagree? Let’s have a conversation.

1 Stop trying to keep your team “busy”. Chasing high utilization is a recipe for catastrophic collapse. Encounter one unexpected setback, and the whole system crumbles. Instead, build in a safe level of slack to absorb the ebbs, flows, and hiccups. The snakes are invisible in knowledge work:

Watch out for the waiting snakes …

2. Stop managing large planning inventories. Your goal is to invest time at the last responsible moment. What use is talking about something you’ll work on two months from now? The context will likely change, and that time spent planning will go wasted.

3. Stop attempting to “get ahead” of projects in small groups, without the whole team present. It rarely has the desired effect. End what you’ve been working on, pause, breath, and then tackle the next mission together. Build shared understanding collaboratively with the team. A well-oiled team can ramp up on a new challenge in a couple of days.

4. Stop believing estimates can help you plan. It’s easy to play three-dimensional chess with your initiatives: “If A will take a long time, then it is better to do C and D!” The reasoning is sound, but it rarely pans out. Often, you’ve failed to slice out the parts of A that will be truly valuable. Or, more commonly, this suggests a deeper issue with priorities.

5. Stop multitasking! Doing three things at once prevents the team from delivering value early, and rarely beats working serially.

http://www.slideshare.net/JelenaFiodorova/teamwork-agile-way

6. Stop saying “we might as well while we’re at it.” It is tempting to tackle less valuable work because it is convenient. If the team happens to be in that area of the code, we pile on the requests. Pause and ask what is stopping you from tackling your most valuable opportunity.

7. Stop finishing for the sake of finishing. If you’ve discovered your current effort will fail to drive value — especially considering the high costs of maintaining features — then just walk away. The sunk-cost bias is incredibly powerful.

8. Stop grouping work into large batches. Yes, they feel more comfortable and efficient because batches tend to incur a transaction cost. Think instead how you can lower the costs associated with delivering small batches (test automation, investing in DevOps, writing release notes, feature toggles, etc.) Large epics take on a life of their own and expand to fill the available space.

9. Stop forcing premature alignment/convergence. Creativity and diversity drive novelty, passion, and innovation. Pressuring the team to “be on the same page” can thwart the journey towards discovering the right page!

10. Stop trying to solve problems with process alone. It is tempting to believe that you can fix things with a slightly better process, tool, structure, or report. Or that things will transpire exactly how they’ve played out in the past. That’s rarely the case. It can be difficult to predict what will work in a rapidly changing environment. The alternate is to try what Dave Snowden calls “safe to fail probes”.

Safe-fail Probes are small-scale experiments that approach issues from different angles, in small and safe-to-fail ways, the intent of which is to approach issues in small, contained ways to allow emergent possibilities to become more visible. The emphasis, then, is not on ensuring success or avoiding failure, but in allowing ideas that are not useful to fail in small, contained and tolerable ways. The ideas that do produce observable benefits can then be adopted and amplified when the complex system has shown the appropriate response to its stimulus.

This point is made hilariously clear in Snowden’s advice for planning a children’s party …

Product! Stop Whining About Sales!

As Product folks, we need to stop whining about Sales. We aren’t the victim. We need to break out of the “glass case of emotion”:

Product! Stop Whining About Sales!

As Product folks, we need to stop whining about Sales. We aren’t the victim. We need to break out of the “glass case of emotion”:

https://www.youtube.com/watch?v=5fmHCNfowbQ

It’s our fault …

It’s our responsibility to shape a product that is easy to sell, easy to use, enables excellent outcomes for our customers, AND has a winning growth model. If that doesn’t exist, it is perfectly reasonable to expect our team — the broader team, including sales — to “[flow like water](http://www.goodreads.com/quotes/29138-be-like-water-making-its-way- through-cracks-do-not)” and take the path of least resistance. If that path doesn’t lead to the product as it exists today, then the path is broken, not the people.

Selling to the “right” people should be 100% natural: great customer experience resonates with the “right” people, referrals happen, case studies materialize, personas start to dot the wall and everyone zeros in on the sweet spot.

Selling “in the box” should be 100% natural because the box addresses a compelling pain point, even if it’s rough around the edges. And when it comes time to renew, the “right” product (and team, and service delivery approach) will renew itself without roadmap promises.

When that doesn’t happen, the organization becomes imbalanced and odd incentives percolate. Consider how you’d react in the same situation with a quota hanging over your head. You’d lodge yourself in the biggest and gnarliest deal you could find to [slay the elephant](http://andymonfried.blogspot.com/2006/02/elephant-hunting-in-sales- term.html). Or churn out sub-optimal deals. We humans are pretty darn scrappy.

It’s your job as product person to point the way and make the case. If you are still in learning mode, then make that clear!

The product can be easy to sell, but hard to use (Brita water filters). Or insanely valuable, but difficult to get into the hands of the right customer, and turn into a successful business ([insert 50% of cool IoT Kickstarter projects](http://arstechnica.com/business/2014/10/the-ugly-afterlife-of- crowdfunding-projects-that-never-ship-and-never-end/)). Step back for a moment and consider everything your company does as The Product. Your support is The Product. The way your salespeople interact with customers is The Product. Your marketing is The Product. The product “works” when all aspects of the service — yes, probably best described as a service, not a widget — are in harmony.

The challenge of getting this right was my primary motivation for joining an analytics company focused on product teams. Consider the problem. Cold hard cash, or a contract, has a way of trumping murky, disparate, and difficult to extract data. That impending deal feels real. It feels actionable. But we all know the slippery slope that can take us down.

There’s a reason why the product team is (often) viewed as the whipping boy of the organization. We talk a big game but rarely have the data and evidence to back up our gut. We try to care for the big picture but have trouble painting the big picture. Or we lead by fiat, and erode trust.

But there’s an alternative. Easy to extract, easy to present, and easy to act on evidence trumps all. Yes, this requires a cultural shift. But that’s part of why you signed up.

So with that, stop whining and take responsibility for your product! Discover a lucrative sweet spot and build something that exploits that information. Use evidence (qualitative and quantitative) to tell a compelling story. And, show empathy to your sales team!

The Killer Sales Instinct vs. Startup Validation

As a rickshaw driver in NYC, I had my sales routine down pat.

The Killer Sales Instinct vs. Startup Validation

As a rickshaw driver in NYC, I had my sales routine down pat.

Midwestern Couple in Times Square … “you folks like to take a tour of Broadway? And then Central Park?”

Business Person, Park Ave, at 5 PM … “no cabs around, can I get you to Grand Central for $20? 5 minutes!”

Lower East Side … “um, you know, hey, you guys need a ride to the Save The Robots.”

When I picked up Ben Stiller and Dennis Rodman one night, I knew to ride instantly AWAY from the paparazzi. I learned this through lots of trial and error, undercharging, and losing my voice. It took months, but I got to the point where I could come home with a couple of hundred bucks on any day of the week.

Manhattan Rickshaw Driver

I also learned that killer instinct. Not everyone had a great ride in the rickshaw. But I knew how to get them to take the plunge and agree to $30 for 10 minutes of watching a scrawny kid pedal them three blocks. That felt shitty. Especially when it was raining. But I needed to pay rent.

We are persuaded all the time to buy things we don’t need or use. Someone wins. We lose. But with services — and I regard most software as a “service” these days — you typically can’t succeed that way. You rely on someone coming back. Unfortunately, so many of our methodologies are stuck in the “old” ways of physical and shippable products … front-loaded to trigger the purchase decision vs. the retain decision.

A billboard from Croatia. He is actually offering truffles to the goddess. Go figure.

The job of Product Development and Marketing becomes exponentially more challenging when you cater to different personas. It isn’t linear. Three is way more difficult than one. Every meeting becomes more difficult. Every UX decision becomes more difficult. Every prioritization meeting becomes more difficult. Every support case becomes more difficult. You just slow down. There’s no way around it, and even late nights will not stem the tide.

With marketing, it is no easier. You can’t market to Classical Music fans and Nascar Fans at the same time, even if they both need to go on a diet. The approach will be different. Everyone wants to lose weight (the pain sells decently well), but Bach aficionados and Kevin Harvick junkies are a different breed. In both cases, the miracle diet goes unreturned, despite the 30 day refund.

Selling to learn, and selling to sell is a fundamentally different task. The minute that killer instinct bubbles up — that competitive drive to close the deal, that paranoia about the deal falling through, that fear of hitting the number — you’ve already lost your ability to learn about certain things. You’ll learn how to morph the message to the audience (like I did countless times as a rickshaw driver), but you won’t learn about the big picture.

Always Be Closing

Get them to sign on the line that is dotted.

This is not a fundamentally bad thing. Some of us never learn how to turn that drive on. It’s just a matter of timing. The time WILL come, but the time is not now. That killer instinct is both an asset and liability.

The “learning” that needs to happen is: can you target someone with marketing, pitch them, close them, get them to use your product, and make them insanely happy as a customer? And do that repeatedly without insane heroism, and a limited resource (like a psyched founder)? It’s something the growth hacker movement has figured out.

Your goal as a startup is to figure out your formula, not to grow immediately, and not to hit numbers at all costs. It is a learning process. Most assume that by setting goals and quotas they can tease that learning out. The problem is that most people are wired to swim at all costs and not drown. It’s human nature.

So, in closing, show your sales friends some empathy. Engage them in the process of learning and incentivize them to learn. To reduce them to simplistic bloodhounds — smelling blood, and chasing down deals at all costs — is a disservice.

Pick a buyer persona and stick with that group. Run the test!
Test one or two techniques simultaneously (scripts, marketing, on-boarding, etc.)
Be willing to walk away
Stop fetishizing sales heroics. Fetishize learning heroics!
Form shared understanding around a typical journey map that spans teams

100 Product Development Hats

Stop thinking about titles in product development. Start thinking about Hats. Why? Because it takes 100+ Hats to build an awesome product.

100 Product Development Hats

Stop thinking about titles in product development. Start thinking about Hats. Why? Because it takes 100+ Hats to build an awesome product.

Too often we focus solely on accountability, alignment, and efficiency. This fixation frequently manifests in silos, politics, title obsession, and hierarchies. Instead of focusing on what we need to build an awesome product— safety, trust, and a diversity of viewpoints and skill-sets — we sub-optimize to preserve the neat and tidy boxes. The turf-war benefits no one. And neither does creating a shadow market of skills where people are not acknowledged and recognized for the work they really do.

**So what do you need? What does your product need? What do your teams need? **Talk over these needs and hats with your team. Be flexible. Let people do what they’re good at, or want to learn more about. It will be “messy”, but the neat and tidy just results in crappy product.

Go Towards The Discomfort (It’s A Sign)

… and stop doing things that make sense

Go Towards The Discomfort (It’s A Sign)

… and stop doing things that make sense

Illustrations by Claire Bowman. Editing help from Kate Maurer.

I woke up yesterday, but felt like I hadn’t slept. A bunch of leftover work week worries bubbled up, stirred up by some good ol’ [imposter syndrome](http://www.nytimes.com/2015/10/26/your-money/learning-to-deal-with- the-impostor-syndrome.html?_r=0) (preparing for conferences will do that). Notifications buzzed from my phone in the other room. Sun dripped through the blinds — it was going to be a nice day. Then there was that moment of tension:

Do I get out of my head, go out, see friends, and enjoy the weather (which I know is 100% effective at making me feel better), or do I withdraw and spend the day working and mulling over my angst?

I often opt for the latter, with reliably poor results. Weird, right?

You’ve felt that before. Maybe not with work angst, but with something: picking the healthy food option, choosing to exercise after a long day at work, giving someone a second chance, checking to see if the stranger on the street is OK, or listening when you want to talk. Sometimes it is a simple case of short-term benefit versus long-term gain. At other times these small decisions cut straight to our fears, self-perception, and self-doubt.

Part of the brain is saying “You know the right thing to do! Push through! Take a risk!” But there’s that other voice saying “That’s hard! Keep the status quo! Make it go away! Time for dessert!” Should we do something that feels unnatural, dangerous, impractical, uncomfortable, worrying, challenging? Or do we just roll with it?

That uncomfortable moment is a sign. It’s a beacon.

We experience these small decision points every day — as individuals, in relationships and families, and as organizations and communities. But if we opt for one path repeatedly, the beacon fades to a faint blip, and our neural connections harden and stiffen. When that happens, we turn on the autopilot (also known [System 1 thinking](http://bigthink.com/delancey-place/the-two- systems-of-cognitive-processes), or the aptly named [lizard brain](http://sethgodin.typepad.com/seths_blog/2010/01/quieting-the-lizard- brain.html)). In this mode, we act without thinking, and generally let our fears rule us.

Until that happens, we have a chance, because we sense that moment of tension. And that moment is an opportunity. Those small decisions add up.

What applies on the individual level also applies to how we work together in communities and organizations. The road to organizational dysfunction is paved with many common-sense, split-second, well-meaning, and very human decisions.

If you ask most people what they value in a work situation they will describe things like autonomy, diversity, open communication, challenge, honesty, coherence, a sense of purpose, and acknowledgment. Even more fundamentally, we require safety, trust, and respect.

Contact me for a higher res version. This is a work in progress.

We set out with the best intentions, but go astray. Our many “common-sense” decisions result in outcomes that run counter to our values, and over time a stark incongruence settles like a fog. How often do we compromise on quality, or humanity, or diversity, or trust, or transparency? Often. And that is when things slip.

Some of these choices are automatic, and there’s no time to pluck the signal from the noise. But, in most cases, there’s that glowing beacon — that split second of tension and resistance — that indicates a better path is possible.

You’ll often know these moments just by the words you use. Do any of these snippets sound familiar?

You’ll have to do that, because, well…just because.

Perhaps we shouldn’t share that information. It might anger people.

Let’s be practical. There’s no way that will work here.

How can we say no at this point? We’re in too deep!

Well, it’s human to just be worried about your own quota.

We can let it slip just this one time. No one will notice.

You and your coworker probably know that you should NOT talk about someone behind their back. You know you SHOULD include them and get real, but habit kicks in. And there’s the challenge.

It’s human to buckle, and it’s human to take uncomfortable risks. It’s also human to delude yourself, but also human — and possible — to get to yes with yourself. We are simultaneously creatures of habit and creatures of insight.

Which is awesome, if you think about it. We’re not doomed to repeat our mistakes and send our organizations into an ugly spiral. The trick is to sense those moments — the spark, instability, tension, momentary fear — and go toward the discomfort. Adopt the beginner’s brain, and let that be your guide.

We can sniff out these opportunities because they have many common traits. You can help your teams learn to be aware of them. To hone their radar — not for a particular solution, not for “the way,” but for an opportunity.

At the core here we have a very human challenge, compounded by having LOTS of humans in the picture. One response is to call the steady slide some variant of the human condition, throw your hands up, and resign yourself to a steady [drift into failure](https://www.govloop.com/community/blog/how-organizations- fail-part-two-drifting-into-failure/).

Another perspective — the one I’ve been taking lately — is that every decision is an opportunity: in our personal lives, in our work lives, and at the intersection of the two. We can turn to face the discomfort and move forward, or we can keep the status quo. In the process, we’ll mess up — that’s life. But it’s the meditative practice of sensing these moments of tension, acknowledging the path of habit and inertia, and taking the uncomfortable route that counts.

How can we, as individuals, be clear with ourselves, and then bring that to our organizations? It starts with emotional safety, and in the end requires facing our discomfort. But it is possible.

Your Product is a Service…

What is The Product? What is Your Product?

Your Product is a Service…

What is The Product? What is Your Product?

Your Product is …

Every prospect/customer interaction and touchpoint
Every interface, application, bit, byte, atom, and circuit
The collective learning of your organization
Your ads, brand communication, press, and social media presence
Your content, the words you use, the emotions you evoke
Your sales methodology, emails, calls, and visits
Your help documentation, customer support, and webinars
Your post-sales/onboarding experience. Your billing department
How you treat the customers you lose, and the prospects that say no
Your code quality, data-centers, infrastructure, and test coverage
The worst behavior you tolerate on the part of your leadership and team

Product is not something you “ship”. Increasingly, it is a service that the whole organization _delivers continuously. _Tossing things over the wall isn’t going to cut it. Dividing up your organization will restrict the flow of valuable information. Aligning yourself around anything other than the end-to- end customer experience is a form of sub-optimization. Any poor user experience — using the software, on the phone with support, learning, buying, or renewing — can sink you.

So when folks go on and on about defining product management … ask why? The product is everything. Don’t let the anchor of old ways of delivering physical software products weigh you down. You’re in the service delivery and design business now. Embrace it!

Real World Kanban (A Cartoon)

So you’ve been trying this Kanban thing. It’s working out great …

Real World Kanban (A Cartoon)

So you’ve been trying this Kanban thing. It’s working out great …

What Does “Sales-Driven” Even Mean?

I frequently use the term “sales-driven” and contrast it with other focus descriptors like product-driven, technology-driven, and marketing…

What Does “Sales-Driven” Even Mean?

I frequently use the term “sales-driven” and contrast it with other focus descriptors like product-driven, technology-driven, and marketing-driven. Until recently I didn’t give the phrase much thought. I sort of knew what it meant — and so did most people I spoke to — but to be honest I had a tough time describing it. So what do I mean?

When taking a sales-driven approach you:

Prioritize the curb-appeal of your product over long-term customer value. For example, you actively build and sell flashy features which provide limited lasting value or fail to deliver on the sales promise. In short, you focus on what sells or attracts attention vs. what works
Allow sales opportunities to impact the product roadmap disproportionately. Agreeing to build something for a prospect is a major commitment, as even the savviest prospects tend to botch their requirements. It is also rare for a hastily developed feature to be productized vs. being held together with bailing wire for the customer. More often than not, the sales-driven roadmap item becomes a liability and sits in limbo.
Let sales dictate the target persona (or lack thereof). As product people, we build products with specific “jobs to be done”, people, needs, and psychologies in mind. In a sales-driven approach, there will often be a mismatch between product’s target end users, and the people you sell to. Sometimes the sales target is simply broader, but often it is just plain different.
Saying No is one of the toughest things in product management. When selling, you’ll inevitably hear about ancillary and complimentary needs. They love your product, and if it can do [insert something else] they’ll love it even more. A sales-driven approach tends to guide your product management hand a bit broader than a product-driven approach.
A sales-driven company tends to prioritize developing new features over optimizing existing features for existing customers. A bulleted list of features is the calling card for new sales. The bigger the list, the more doors that open.

Most businesses need some form of sales. You can be amazingly good at sales, but not be sales-driven. A product-driven company doesn’t stop selling … rather it puts more emphasis on assuring that customers get value out of the product vs. drive the car off the lot. Before jumping to the next feature, you validate that you’ve hit the mark.

As a UX-centric product person, I tend to feel better about my work when I’m working in a product-driven setting. It just feels more focused, sustainable, and impactful. I’ve also been bitten numerous times by the byproducts of a prolonged sales-driven effort. That said, countless businesses have succeeded by taking a sales-driven stance. On some level, it boils down to your sense of craft, and your tolerance for things to be a little less-than-ideal for your existing customers.

And with some products you have no choice. The market is competitive, busy, and fierce, and it is hard to sell on differentiation. No matter how you slice it, your product is not going to sell itself. You will win BECAUSE you learn how to out-sell and outmaneuver the competition. Like it or not, your product is secondary.

45 Posts On Product Development

I turned around today to realize that I just published my 45th Medium Post.

45 Posts On Product Development

I turned around today to realize that I just published my 45th Medium Post.

Some of it is crappy. Some of it is inspired. Typos. Angst. I’ve done it all.

But there has been something very meditative about sitting down and cranking one or two out each week. It has helped ME clarify my point of view.

Given that Medium doesn’t have a great index feature, I figured I’d provide one here. I’m grateful for the folks who have taken the time to read and comment.

May 2016

[45: Before You Join A Startup …](https://medium.com/p/before-you-join-a

-startup-2ca1fae490cf)

Some realities of joining a venture-funded startup

When you join a venture-funded startup, remember that you’re playing someone else’s game.

[44: What Does “Sales-Driven” Even Mean?](https://medium.com/p/what-does-

sales-driven-even-mean-7a6ee976f1ef)

I grapple with what defines a sales-driven organization

Prioritize the curb-appeal of your product over long-term customer value. For example, you actively build and sell flashy features which provide limited lasting value or fail to deliver on the sales promise.

[43: Real World Kanban (A Cartoon)](https://medium.com/p/real-world-

kanban-a-cartoon-116fd37f14ac)

What do most Kanban boards look like?

[42: Your Product is a Service…](https://medium.com/p/your-product-is-a

-service-f70d92b7e992)

Your product isn’t confined to what you ship. Your product is the whole organization

Product is not something you “ship”. Increasingly, it is a service that the whole organization delivers continuously

April 2016

[41: Go Towards The Discomfort (It’s A Sign)](https://medium.com/p/go-

towards-the-discomfort-its-a-sign-21ce4b1a8cc5)

I partner with my friend Claire to dig into life’s tough decisions. And why we should, as a good heuristic, do things that are uncomfortable

It’s human to buckle, and it’s human to take uncomfortable risks. It’s also human to delude yourself, but also human — and possible — to get to yes with yourself. We are simultaneously creatures of habit and creatures of insight.

[40: 100 Product Development Hats](https://medium.com/p/100-product-

development-hats-7fabbded6b8d)

Titles don’t mean much in product development. It takes many hats to build something awesome

[39: The Killer Sales Instinct vs. Startup

Validation](https://medium.com/p/the-killer-sales-instinct-vs-startup- validation-da705b93c40d)

Why a great sales approach doesn’t necessarily aid in validating your startup’s growth model

[38: Product! Stop Whining About Sales!](https://medium.com/p/product-

stop-whining-about-sales-dcd10640ded4)

Product is to blame when sales attempts to sell “outside the box”

It’s our responsibility to shape a product that is easy to sell, easy to use, enables excellent outcomes for our customers, AND has a winning growth model.

[37: 10 Common PM Intuition Traps](https://medium.com/p/10-common-pm-

intuition-traps-5a1ec5b3bdaf)

Sometimes what makes sense doesn’t make sense …

[36: Opening Your Eyes to Real Customer Delight](https://medium.com/p

/opening-your-eyes-to-real-customer-delight-80e3a883bd93)

We often rationalize sub-par customer feedback. What do delighted customers look like?

I’d argue that many of the product metrics we capture (e.g. engagement, conversions) are proxies for less tangible things like customer delight, advocacy, and product focus. The hard metrics can be used to predict churn and trial conversions, but they fail to cut at the central question: Is our product truly inspiring our customers and kicking ass?

[35: Stop Setting Up Product Roadmaps To Fail](https://medium.com/p/stop-

setting-up-product-roadmaps-to-fail-3189452360a3)

What job are you hiring your roadmap to do? Are you setting it up to fail?

[34: A SaaS Startup Cautionary Tale](https://medium.com/p/a-saas-startup-

cautionary-tale-dcf7eabd6402)

Video showing a common startup anti-pattern

March 2016

[33: How Much Does A New Feature Cost?](https://medium.com/p/how-much-

does-a-new-feature-cost-f93c82bf638f)

New features cost a lot more than you think. There are many hidden costs

[32: Time Management: Tips for Product Managers](https://medium.com/p

/time-management-tips-for-product-managers-925e4ac5efa9)

Product management is tough! How you manage your time can save your sanity

[31: Your Startup: Food Truck or Buffet?](https://medium.com/p/your-

startup-food-truck-or-buffet-e619c818c190)

Are you trying to please everyone? Are you nimble enough to move/pivot if you need to?

[30: Decision Making Transparency (The Why)](https://medium.com/p

/decision-making-transparency-the-why-7f90e48fded)

Explaining why you’ve made a decision is often more important than explaining the decision. The “what” may change, but the motivations remain powerful …

In the swirl of growth, it’s easy to confuse and conflate transparency on the decision making process, with transparency on actual decisions and details.

The Why is scalable because it carries the original intent of our decision, and not just the tactic.

[29: 12 Core Competencies For Product Managers](https://medium.com/p/12

-core-competencies-for-product-managers-8d5744f91bd)

Hiring a product manager? Look for these core competencies

[28: What Startup Sales Can Learn From UX](https://medium.com/p/what-

startup-sales-can-learn-from-ux-7742bcc6a6cb)

Sales and UX have a lot in common. Both look for the pain and opportunity

[27: How To Tame Engineers, Be A Rockstar, and Ship ****ing

Product](https://medium.com/p/how-to-tame-engineers-be-a-rockstar-and-ship- ing-product-f24f059d4a7)

One of my most scathing/angsty pieces. Basically … all the worst things you can do as a product manager

To be successful we want engineers to relish their craft, and to take pleasure delivering exactly what we want them to deliver.

[26: Team Health: A Daily Checkup](https://medium.com/p/team-health-a

-daily-checkup-2acebe65f6da)

A quick daily team health checkout template

[25: A Better Roadmap | Mind-Map | Mousetrap](https://medium.com/p/a

-better-roadmap-mind-map-mousetrap-cdbacaaa664b)

A video covering an approach to mind-mapping your roadmap and/or strategy

Feb 2016

[24: Getting The All-Hands Right](https://medium.com/p/getting-the-all-

hands-right-fadc53f8317c)

Tips for your company all-hands

[23: Talking The Talk: 32 Conversation Prompts for Product Development

Teams](https://medium.com/p/talking-the-talk-32-conversation-prompts-for- product-development-teams-9af024a1ac5)

Mad libs for getting your product development team to start having the right conversations

To feel more confident about our decision to ________, I would like to observe ________

Example: To feel more confident about our decision to add steps to the workflow, I would like to observe more customers completing the existing workflow

[22: To Experiment Is Human. Reality is a **cker. And The Law Of Two

Feet](https://medium.com/p/to-experiment-is-human-reality-is-a-cker-and-the- law-of-two-feet-639ade01396a)

I dig into the human need to experiment and have impact. And how when you don’t have that, you should use your two feet and move on

Most organizations are structurally and culturally incapable of making it safe for teams to experiment and occasionally fail.

[21: Focus Until It Hurts](https://medium.com/p/focus-until-it-hurts-

923ddab03e71)

Startups talk about focus. But what does focus REALLY feel like?

Jan 2016

[20: The Iron Triangle Is Dead](https://medium.com/p/the-iron-triangle-

is-dead-4cbb2aecd71d)

Why safety and diversity are essential … everything connects

[19: Persona(s) Non Grata](https://medium.com/p/persona-s-non-grata-

5587cb46409c)

Tips on better personas, and how to defeat common objections

[18: 50 Interview Questions For B2B SaaS Customer

Research](https://medium.com/p/50-interview-questions-for-b2b-saas-customer- research-ecdc093c5127)

You’re about to do a B2B Customer interview. How to you ask non-leading questions that uncover valuable opportunities?

[17: As Product Managers We’re Asking Ourselves The Wrong Set Of

Questions](https://medium.com/p/as-product-managers-we-re-asking-ourselves- the-wrong-set-of-questions-badfcfc6eb20)

Stop wasting your time trying to define product management. Ask Why.

In my view we’re asking the wrong question. We’re replacing a tough discussion of values and principles — as a whole team, not just as product managers — with discussions about titles, job descriptions, the org chart, and handoffs. The best perspectives on product development [have nothing to do with defining and boxing a title](https://medium.com/@stewart/we-dont-sell- saddles-here-4c59524d650d#.w2rffmxtb).

[16: This PM Hack Saved Me 1 Hour A Day (and helped me connect with more

customers)](https://medium.com/p/this-pm-hack-saved-me-1-hour-a-day-and- helped-me-connected-with-more-customers-fbbb76c2ba2d)

A quick hack for booking customer interviews

[15: The Way Of The Product Whatchamacallit](https://medium.com/p/the-

way-of-the-product-whatchamacallit-9929a78d6694)

Light take on effective product development teams

[14: Hidden Costs of the Sales-Driven Roadmap](https://medium.com/p

/hidden-costs-of-the-sales-driven-roadmap-81b847da3452)

The costs of a sales-driven roadmap are not always immediately apparent

[13: 10 Questions For Your (Product Role)

Interviewer](https://medium.com/p/10-questions-for-your-product-role- interviewer-8fd90983049a)

Interview the interviewer. How to gauge whether the opportunity is the right fit

[12: User Stories and Data](https://medium.com/p/user-stories-and-data-

32057117fc7b)

Tips on incorporating data directly into your user stories

Dec 2015

[11: Juggling Growth and Usability: A UX Debt

Primer](https://medium.com/p/juggling-growth-and-usability-a-ux-debt-primer- af92d7a08c35)

Battling the dreaded UX Debt demon. It’s never easy, but you’ll have to pay it down eventually

[10: 104 Questions For Product Development

Teams](https://medium.com/p/104-questions-for-product-development-teams- 5bc2dbae690e)

The biggest listicle of all time. Question prompts for your product development team to ponder at all stages of development

Have we communicated those goals with a compelling vision? Does the vision inspire and focus our work? Can it be explained in a tweet? What is our “true north” ? Is the team engaged?

[9: Product Ownership: 10 Core Principles](https://medium.com/p/product-

ownership-10-core-principles-28e68e5c7622)

10 core principles underpinning the product owner role

[8: Good Process, Bad Process](https://medium.com/p/good-process-bad-

process-c5d6a6a828b5)

Not all process is bad. Consider the “creative process” …

[7: Sticky Love — Choosing Between Physical Boards and Online

Tools](https://medium.com/p/sticky-love-choosing-between-physical-boards-and- online-tools-874a457ebc80)

Physical boards are great. Online tools are efficient. How to integrate the two

[6: What comes to mind first …. love the problem and sense the

impact.](https://medium.com/p/great-post-my-answer-really-is-love-the-problem- and-sense-of-impact-8ea2b901b6c6)

An interesting reply to a thread on product management

help the team fall in LOVE with a customer/user/business (hopefully all three) problem AND then do whatever possible to guide the team towards a sense of real IMPACT.

[5: Life, Death, Continuous Improvement, and Continuous

Disruption](https://medium.com/p/life-death-continuous-improvement-and- continuous-disruption-fd1de8aad6d4)

We are all disrupting ourselves at some point … as teams, individuals, companies, and cultures

Continuous improvement is the response to the drumbeat of atrophy and carrying dead weight. And it works hand in hand with continuous disruption. Basic process improvement and optimization relies on a repeatable future. Continuous improvement addresses a deeper need.

[4: Dr. Obvious, Startup Validation, and Failure](https://medium.com/p

/dr-obvious-startup-validation-and-failure-63709d1779ec)

You are running “tests” if your tests never fail

[3: Inside My Kindle: 100 Books For PMs, UX, Entrepreneurs, Systems

Thinkers, Design Thinkers, and…](https://medium.com/p/inside-my-kindle-100 -books-for-pms-ux-entrepreneurs-systems-thinkers-design-thinkers-and- 7a1a6cf05ec3)

All the books in my Kindle. In one place

Nov 2015

[2: 8 Trends Shaping Modern Product Management](https://medium.com/p/8

-trends-shaping-modern-product-management-29953562e5f0)

Classic trend listicle

[1: The System Thinking Change Agent Survival Guide](https://medium.com/p

/the-system-thinking-change-agent-survival-guide-5ab8e7a8521f)

How to survive when you’re always asking “why” …

Before You Join A Startup …

When you join a venture-funded startup, remember that you’re playing someone else’s game.

Before You Join A Startup …

When you join a venture-funded startup, remember that you’re playing someone else’s game.

There are plenty of business models — creative agencies / consultancies, for example — that group people by a passion for doing great work and making a reasonable salary. Most venture funded startups are not in this category. So you have to come to accept that.

One of the harshest realities of the startup world is that what can be good for your investors (and founders even), might not jive well with your sense of craft, responsibility, and happiness. And that’s no one’s fault. It just is how it is. The economics, risk profile, and odds dictate the tactics. The letdown comes when you believe otherwise.

<http://techcrunch.com/2014/05/24/deciphering-the-economics-of-venture- capital/>

What is right for the customer, right for your sense of intellectual rigor, and right for your sense of a job well done, aren’t always right for someone else’s portfolio. Again, you’re playing two different games. You might be trying to grow a healthy vegetable garden. They’re trying to build an oasis in the desert. Your veggie garden is the much derided “lifestyle business”, while their oasis is the Unicorn. Neither is bad.

Reality check: some of the biggest venture “wins” come from land-grabs, vaporware, accu-hires, and mediocre products. Interestingly, these wins are often followed by refocusing on impact and culture — a big reversal — but that’s for another post.

I remember being involved in the music business and watching my friends struggle with the harsh world of the major labels. One month you were on top of the world and the next month you were basically in $120k of debt to the label. Without that hit single, you weren’t much good to anyone. For better or worse that’s how much of the startup world works.

Much of the startup world revolves around the heuristic that high growth validates the business model, and that you can always find more efficiencies down the road. Unfortunately, this provides little solace to those on the front-lines. “Making the number” often doesn’t equate to “job well done” (unless you’re in sales). Some folks like Jason Fried and David Heinemeier Hansson (DHH) have advocated heavily for the craft and empathy focused middle ground, the “indie rock” of the startup world, but that is rare.

This tension forms the backdrop to countless startup water-cooler conversations (or private Slack channels, or coffee maker chats … pick your poison). It happens so predictably and consistently that it almost feels cliche. Anyone who has done their time in startups knows the script.

As an individual, it is important to ask yourself the hard questions. What inspires you? Why do you show up day after day? Are you in this for a small chance at a big upside? If it all burns to the ground — and most of the time it does (financially, morally, culturally, or otherwise) — will you be happy you were along for the ride?

The startup world holds a certain seduction. It is stripped of the politics, the hard-and-fast rules, and the monotony. But remember to take a step back and look at the big picture.

I love startups. I love the ride. But I’ve learned to understand (and respect) it for what it is. And alas the irony: at some point you’ll have your own thing and need to make the hard decisions. It’s never easy, but it’s always interesting!

Quit Planning Ahead and Keeping People Busy

As product people, we need to work more on the mission and less on playing Tetris with teams and initiatives. To much planning ahead and…

Quit Planning Ahead and Keeping People Busy

As product people, we need to work more on the mission and less on playing Tetris with teams and initiatives. To much planning ahead and chasing full utilization will undo your product.

Oh oh! We we can finish that in 6 days, right?, and then we can rotate them to project Z, and … oh, well Mandy will be done with that thing, and we can slide that project in there. If they finish that afternoon, Bill will present his mockups and we can start on …

Your average PM will spend countless hours in meetings talking to non front- line stakeholders about what their organizations will (or should) do at some point in the future. They’ll make fancy gantt swim-lane roadmaps so that everyone feels heard. And then talk about pet solutions, show mock-ups, make a lot of guesses, play Tetris with initiatives, and pester engineers for estimates. Towards what end? Why?

https://siouxnetontrack.wordpress.com/page/8/

They sincerely believe that this is their only option. Ironically, the more they do it, the worse the results, and the more people feel that premature alignment and multi-tasking are necessary. I mean gosh-golly, if we could just “hit our commitments”! It’s a vicious cycle. But it doesn’t need to be that way.

A microscopic amount of this “planning ahead” adds value. It is a symptom of our preoccupation with full utilization, and it makes things WORSE.

We try to work out all the details in small groups so as not to “distract” the teams while they juggle the four other things we’ve asked them to do. UX hurries to prepare mock-ups (in isolation) so that the team will be able to get started right away. More colorful lines get added to the roadmap swim- lanes. And then what happens?

http://connectedprincipals.com/archives/10412

We spend days/weeks trying to re-calibrate with the reality on the ground, get the team engaged with a vision they had no part of, and work through all of our faulty assumptions. And then rush to get the feature shipped to shut everyone up only to find we missed the mark because our batch was huge and we had 10 things on deck.

Consider the alternative. The reality is you only need to plan for the very next thing. And only in broad strokes. What counts is the mission: the engaging outcome you hope to generate for your customers and business. Focus instead (like 90%) on being present for the important task at hand. All this other stuff — the freakish alignment meetings and pre-planning — is just driven by people freaking out over nothing getting done.

What if the team finished what they were doing, and then engaged in a couple of DAYS of collaborative design, spikes, and research? It might feel less efficient, but it is far more effective. UX would sit down and work directly with engineers to explore what was possible. Instead of paper prototypes, you’d try testing working prototypes with real customer data. Simply put, you’d be getting it done right.

Take a step back, and ask yourself the hard question. Is any of the pre- planning worth it? Really? If the team produced constant value and you could prove it, would anyone care? Of course not, they’d keep letting you plow along. Most people can’t because 80% of shipped features never really get used or hit the mark. So as an alternative, we seek full utilization and the fastest delivery of stakeholder guesses. That becomes our job.

Wrong! Don’t go there.

One of the biggest tips I can give product development teams is to keep the planning inventory as low as possible. Get alignment on the mission, and stop fixating on pet solutions. Slow down and focus to speed up. Don’t chase full utilization. Let the team breath. Finish one thing and then start the next thing. You’ll produce better results and move much faster.

Enter Through The Narrow Gate (Go Deep)

Enter through the narrow gate. For the gate is wide and the road is broad that leads to destruction, and there are many who go through it…

Enter Through The Narrow Gate (Go Deep)

Enter through the narrow gate. For the gate is wide and the road is broad that leads to destruction, and there are many who go through it.
Matthew 7:13

Going broad is dangerous.

Imagine opening a sushi restaurant catering to both sushi aficionados and sushi newbies. Try to decorate it to be a great date spot and a convenient lunch option. Make it accessible to cost-conscious foodies and jet-setters. Hire staff that can communicate with your Japanese clientele and explain sushi to traveling Swedes. Seat people for 25 minutes and 3 hours. Does this sound feasible?

Not really. I wouldn’t bet on it.

This type of broad focus is known as “going broad” and it is a startup killer. Everything above falls under making “great sushi”, but the devil is in the details. When it comes to startups, how do you know if you’re going too broad?

You have to produce different marketing material for different buyers
You find yourself dividing your limited resources among different product lines or value props
You have a tough time understanding why a particular customer chose your product
You find it difficult to prioritize work because the data is contradictory
The features you do release only appeal to a small % of your customers
Your support team struggles to service a wide variety of use case
Your customers consider your product both “complicated” and “simple” simultaneously
You take on service / consulting work to address the many edge cases
You frequently receive diverse feature requests in the pre-sales process
You find yourself describing your value proposition as being that of a platform, or a one-stop shop

As a startup PM, you’ll be always tempted to go broad. The temptation will be fierce. Personally, you love your product, and you believe everyone should too. It’s awesome to hear about all the compelling use cases people are dreaming up, and all the minor (and major) enhancements they’d need to make it all possible. So your heartstrings are being plucked.

Externally the pressure can be a lot tougher. Take the sushi venture example above. You might find it easy to get all of those people to walk into your restaurant. Signs and marketing do wonders. You’ve expanded your available market to just about everyone. You might find it possible — through major heroics — to please some portion of those people. All of that will make your team euphoric. And once the ball starts rolling it is tough to put the brakes on. But the mess you make in the process will be your undoing.

“Going broad” means trying to address the needs of too many buyer personas, user personas, AND jobs to be done (desired work outcomes). They all matter. Supporting the same user personas to do multiple jobs is difficult. Likewise, supporting different types of users — even those with the same title — to do the same job is equally complex. The tendency is to overgeneralize. You segment by title (“accounts” for example) and perhaps business size (“SMB”), but that’s about it. The differences between accountants working at SMBs are vast.

We tend to model our startups after large enterprises while forgetting that it took those companies many years (and decades in some cases) to support that many product lines and use cases. It didn’t happen overnight. And it certainly didn’t happen while they were trying to fight for their early existence.

The complexity of everything — product development, support, sales, and marketing — increases exponentially with each buyer/user personas added to the mix. No simple change in process will stem this tide.

So what do you do? I know this will be extremely painful and counterintuitive, but get used to saying no much more than you say yes. By much more I’m talking 20x. Say no to prospects, no to feature requests, no to opportunities, no to expansion, and no to new verticals.

This doesn’t mean don’t sell. Sell your heart out. But sell to one target buyer personas and user persona.

And then, on the flipside, get extremely specific about the Who and the Why. By extremely specific I am talking 20x more precise. People will get super nervous because they’ll assume you’re limiting the TAM (total available market) for your product. Rest assured that you’ll be better in the long run.

So: Say No. And Get Specific.

The Unseen Product is Still The Product

Imagine that you are at a restaurant. As a customer, you interact with the host, the server, the food and drink, and the dishes and decor…

The Unseen Product is Still The Product

My favorite metaphor … restaurants

Imagine that you are at a restaurant. As a customer, you interact with the host, the server, the food and drink, and the dishes and decor. It’s unlikely that you’ll see or be very aware of what’s going on in the kitchen. But it would be wrong to say that you don’t care about the kitchen. You likely care about the cleanliness of the kitchen. You appreciate it when the food comes out quickly. And you’re more likely to come back if the chef has time to create thoughtful and unique specials.

In product development, we tend to think in terms of a wall between the inner workings of an application and the outer, customer-facing side. The inner workings are the work of engineers, and the outer workings are the work of UX designers, interaction designers, and others.

But, if you take a step back, it becomes clear that this line is not a clear one, and that the way an application is built affects usability as much as the outward-facing aspects. How quickly does the software work? How smoothly? How gracefully does it recover from errors? For a customer, the kitchen is as important as the service.

The perceived barrier between engineering and product carries over into the work of teams. We create divisions so that we don’t step on each other’s toes. Engineering says “just tell us what you need” and takes it from there. Product lays claim to the outward-facing aspects and is told not to meddle.

Neither of these views really gets the job done, and the worst outcome is that critical backend work — technical debt removal, refactoring, testing — becomes hidden from view. These goals don’t show up on the roadmap. They aren’t part of a bulleted list. And DevOps teams tend to work on these critical aspects under the radar for fear that the time needed to do them will be grabbed for other priorities. Or, companies sit on debt and delay addressing these issues because they believe that at some later point they’ll have the time.

But product folks need to understand that this all contributes directly to the end-product. It is crazy to turn a blind eye to it. Your next epic might very well be a technical debt workdown, or a test coverage sprint. Not only does the craft of DevOps contribute directly to the overall user experience, but awesomely supported and appropriately architected software empowers you to release product. It’s the foundation that allows you to ship fast and fearlessly and gives you the freedom to experiment and create.

So take a whole-team approach to product development and expand your view of what “customer-facing” means. Don’t let your unsung heroes to go unsung. Embrace the craft of DevOps and seek synergy with an awesome customer-facing UX team. Encourage people to be transparent about what they’re working on. Keep in mind that many of the great products you love are great because of DevOps and a dialed-in process.

You Don’t Need A “Great Product”

There’s an uncomfortable truth about product development:

You Don’t Need A “Great Product”

There’s an uncomfortable truth about product development:

It’s possible to hit the numbers and grow quickly with a crappy product (and/or crappy organizational culture). It’s possible to have a grand exit even when your team knows it is all snake-oil.

You can throw Lean Startup, 4 Steps to the Epiphany, The Hard Thing About Hard Things, and Zero to One in the trash, and still do awesome. Yet we obsesses about “Great Product”.

It will not last and at some point, you’ll end up paying for it. But if your goal is “up and to the right” there are a million ways to grow. If you’re lucky, you can keep this up for a long, long time. Long enough, perhaps, to never have to deal personally with it. Long enough to enjoy a personal exit event, take a break, and come back ready to build a “real” product.

I’m not talking in the very early stages. You’ll need to do something right at that stage. Shortly after that you will see the signs. I spoke with a friend recently who took a roller coaster ride with a big startup in NYC. “Everyone knew from almost the beginning,” she explained, “that our model was unsustainable and flawed. But at a certain point, you just get tired of making the case. Everything was growing and looked good on paper, so we just went with it.”

I hear this over and over. Those on the front-lines sense the problem very early, but it can take years to work it out of the system.

Why does this happen?

Most tech startups make central assumptions about economies of scale. The thought is that eventually, at some point, you’ll figure something out. Someone will want to buy you for your tech (or people), you’ll find new and cheaper channels, or you’ll find the right “synergy” with an acquirer. A lot of tech innovation hinges on long term shifts in usage for “mainstream” business (e.g. Bring Your Own Device, Enterprise Mobility, Big Data, etc.). So it is possible to drink the Koolaid — maybe even spike it — for a long time.

The temptation to just keep growing is just too strong. And frankly, at a certain point it can be tempting to cut product corners and leave certain assumptions unvalidated.

So, let me get to the point. At the end of the day, you need to ask yourself about what you value. What is your mission? What matters to you?

If it’s “go IPO”, “have an exit”, “make shit loads of money”, “get acquired”, or anything like that … well, embrace the optics. Embrace all the ways you can keep the train moving. Play that game.

If it’s “build stuff people love and make a difference” or “build a sustainable model that keeps people employed making great software” (my personal favorite) then embrace that. Let that muse guide you. You’ll need to resist all sorts of temptation to cut corners early on. You’ll need to grow more slowly and be intellectually and emotionally honest with yourself. But just let that be your thing. You might even find that the prior goals just happen organically.

Pick a path with no regrets.

Is Agile Dead?

Is Agile dead? Is it outdated? Does it suck?

Is Agile Dead?

Is Agile dead? Is it outdated? Does it suck?

You tell me … how many of your work interactions are:

Humane
Curious
Observant
Creative
Diverse
Effective
Adaptable
Emotionally Honest
Intellectually Honest
Safe
Hopeful
Sustainable
Respectful
Reflective ?

Maybe for fleeting moment? Maybe for a year during the “good times”? Maybe when you “had a great team once, on that project”?

Exactly. We can always do better. If scrum isn’t your thing, then find something better.

Agile is a reminder that there’s always room for more empathy, happiness, and impact in our work and personal lives. Beyond the infographics, methods, acronyms, debates, books, white-papers, and rants, exists a simple set of guidelines to collaborate, deliver, reflect, and improve by.

This is why I’m so happy to be attending (and speaking at) Alistair Cockburn’s [Heart of Agile conference in Philly](http://heartofagile.com/heart-of-agile- philadelphia/). Because it’s good to give yourself (and your teams) permission to be hopeful and curious.

See you there!

Focus is the Ultimate Process

When confronted with workplace dysfunction, missed connections, or poor communication, we frequently assume that we need to address a…

Focus is the Ultimate Process

When confronted with workplace dysfunction, missed connections, or poor communication, we frequently assume that we need to address a process issue. If we only had the right tools and the right systems, we could untangle things. So we tweak and retweak processes, arrange meetings, and try to get (or buy) systems that promise to link together all of the information team members need and make it all work. But, does it ever _really _work?

What if process isn’t the problem?

We tend to identify problems as process problems when, in fact, they are focus problems.

A great example is the question of how to handle customer feature requests. On the surface it appears as if this is a process problem. How do you track those requests, regularly update customers, and figure out how to prioritize those requests in the product backlog? The temptation is to purchase a bunch of tools and systems and implement a feature request tracking system. But, take a step back. How awesome would it be if your team was always cranking out valuable features? If, rather than fill the pipeline with requests to be managed, you solved a focused problem and had customers lining up due to word of mouth? How could you focus to make that happen?

From a broader organizational perspective, consider something like performance reviews. In truth, we know that intrinsic motivation is what works, and yet we create complex processes and systems of incentives to keep the ship on the rails and to have a paper trail of accountability. But what if none of that was a problem? What would it look like if everyone was held accountable by their own passion for the work?

Process itself isn’t a problem. But when we’re working on process in product development we should consider whether we’re really treating symptoms of a lack of focus. Is that tracking system only needed because we’re trying to do too many things at once? Do we think we need to massively customize a CRM when really we’re just trying to handle too many customers at once? In start-ups it is easy to mistake a problem as one of scaling or “growing pains,” when, in fact, your problem is that you’re trying to cram in as much work as possible rather than [do a few things well](https://medium.com/@johnpcutler/enter- through-the-narrow-gate-go-deep-c2d6528e380a#.o5n8ofmgq).

We need to differentiate between process that enables innovation, and process that is applied from above to band-aid symptoms of a deeper problem. Ideal process can be a dynamic, iterative working agreement among motivated people. But process for its own sake or process that is used to exert control can be poisonous. This is the reason so many management consultants and “change initiatives” fail to achieve their goals.

12 Traits of a Powerful Product Vision

We tend to treat product visions as Tweet-length Mad Libs. They lack bite, resonance, and cohesiveness. It just feels like you’re going…

12 Traits of a Powerful Product Vision

We tend to treat product visions as Tweet-length Mad Libs. They lack bite, resonance, and cohesiveness. It just feels like you’re going through the motions.

But what makes a product vision powerful? To me, the format matters less than the content.

It engages and inspires all members of the team. It presents a goal that unites the development team, the customers and users, and the business. Proposing a business goal without describing the human benefits doesn’t provide inspiration.
It connects the who and the why through a narrative. It identifies the human beings involved and the outcomes you’d like to create for them. It is phrased in a way that identifies its impact on people, even if you’re talking about machines and code.
It has a clear story arc that leads from now into the future. It describes the present state, the change needed, and the vision of a better state.
It is written in language that the whole team understands and avoids marketing-speak or overly technical language. It should be easy to explain to new team members, even if they don’t know all of the details.
It is presented in ways that engage various senses and ways of understanding — visual and auditory as well as verbal.
It is detailed enough to feel precise and focused, but broad enough to leave room for creativity and individuality. Team members have leeway to dream up solutions.
It provides enough direction for team members to take action. It makes it easy for them to make decisions. It provides a true north. Team members don’t need to second-guess themselves or ask for permission.
It is singular and dominant and matches the reality of the team’s activities. Other activities don’t take up 80% of the team’s time. Your vision comprises the 80%, and other tasks are the periphery.
There is a clear goal that the team can strive for in the immediate future, even if the overall vision is open-ended. There are ways to know if you’re on track (leading indicators) and ways to know that your efforts made a difference (trailing indicators and outcomes).
It is achievable, or at least allows for concrete incremental progress. It doesn’t feel purely aspirational or top-down.
It is logically connected to a larger goal, if one exists. If the mission addresses a problem in order to allow progress on a different problem, that relationship is clear.
Team members can take it seriously, knowing that they won’t see the company do things that clash with the vision. No one just gives it lip service. If you were to put it up on the wall, no one would think it was annoying. In other words, it passes the bullshit test.

Where Do We Put The UX Tasks?

In my career I’ve heard this conversation play out over and over:

Where Do We Put The UX Tasks?

In my career I’ve heard this conversation play out over and over:

Eng: “Um, we have no idea what UX is even doing.”
UX: “OK, why don’t we try to add the UX tickets to Jira.”
Eng: “Um. Damn. That many stories? That is going to clutter everything up.”
UX: “Product, what should I be getting ahead of … ?”
Prod: “Well, um, I have this Google Doc you can look at.”
Eng: “What’s next? Is this ready to be worked on?”

I’ve seen teams try these three options to remedy the situation:

Option 1: Keep UX work in a separate system

Product and UX maintains intricate to-do lists for design and research work OUTSIDE of the primary ticketing system.

Pros: It keeps the ticketing system “clean and uncluttered.”
Con: No one knows what UX is working on, and it is impossible to view the dependencies. The backlog is obscured making it tough to get the “big picture”

**Notes: **UXers often have a difficult time explaining the rhythm of their work. They regularly scan for work on the horizon, and “get ahead” of that work by doing research, producing mockups, tinkering, etc. These systems are highly individual. I’ve seen designers use Trello, Basecamp, Google Tasks, stickies, and their notebooks to manage this work. In many cases, it goes unappreciated simply because it is not visible.

Option 2: Track UX work in the ticketing system as distinct and separate

tickets

When UX is working on something, it is described as being In Progress (along with engineering work)

Pros: A clear sense of WIP (work in progress), and the current burden on UX
Con: Too much clutter / too many tickets, and UX work often falls out of sync with release cycle

Notes: The trouble here is that design work itself is not shippable, and again it often doesn’t flow in the same way that engineering work flows. So you’ll finish a sprint and the board — digital or physical — will become cluttered with design tickets. Ideally, you’ll have a “Shipped” status, and therein lies the problem. Unless this design work is related to a customer-consumable / shippable item, it isn’t Done. You could argue that this approach is problematic for user-stories in general. Any time you break up a story based on functional roles (back-end/front-end, for example), you are diluting the story and creating a dependency management game.

Option 3: Track UX as work related to user-focused tickets

UX work is attached to a user-focused story, from early phase backlog refinement to shipped/done

Pros: Clearly describes dependencies. Allows for a “pull” system for design and research which promotes just-in-time work. Remains very user-goal focused
Cons: May require sub-tasks, and multiple people assigned to a particular ticket. Requires strong stories and story splitting practices

Notes: If UX is getting involved on a ticket before engineering (in an analysis/ design/research phase), then it is reasonable to call that work exactly what it is: analysis/design/research. It is similar to the work of engineering architects, business analysts, etc. Some models, like LeanUX, favor less upfront work and eschew the staggered sprint approach. Other teams do a good bit of pre-planning and design before they hand it off to engineering. When the work starts, it typically throws off lots of design tasks along with QA and engineering tasks. These remain with the story.

My bias is for Option 3. It strikes the best balance between:

Preventing unnecessary pre-work (we’ve all had efforts killed after being reassured that the work was, in fact, going to happen)
Keeping the system clean
Reflecting reality
Clearly describing the value-stream, as work further to the right gets closer to release and customer outcomes
Giving “credit” to UX for the work they do that goes unappreciated

Let me know what you think. What has worked for you?

Is It Safe for Your Team to Get “Real”

Industrial Logic’s Joshua Kerievsky writes:

Is It Safe for Your Team to Get “Real”

Industrial Logic’s Joshua Kerievsky writes:

Protecting people is the most important thing we can do, because it frees people to take risks and unlocks their potential.

How true! When I am talking to a new team, there is one thing I zero in on very early in the game. It sits below all the methodologies, practices, cultural manifestos, and vision statements. It is the absolute prerequisite to meaningful continuous improvement.

Can your whole team get “real” when it counts? Is it safe for someone to say:

“I’m not comfortable about where this project is going …”

“We’re feeling a bit bullied lately …”

“I’m overwhelmed, and I can’t reasonably keep up with this workload …”

“This isn’t meeting my expectations …”

“I’m confused about what we stand for here …”

“We aren’t living up to our mission and here’s why …”

Common wisdom says that these types of conversations are out of bounds. You’ll hear arguments like “people aren’t comfortable talking about this kind of stuff” or “this is better off dealt with in a much smaller group.” We seek to contain this talk, subdue it, and silence and control it. Even the thought of “going there” feels a little awkward and scary.

If you let these tensions fester, you’ll often start hearing small groups of people say things like:

“It isn’t worth bringing it up anymore. We just can’t change this.”

“That’s just the way it is. Not much we can do about it.”

“Let’s keep this between you and me …”

“I don’t feel comfortable talking to [my boss] about this. She’s part of the problem.”

“I’m just waiting for the most politically opportune time to … ”

At any given point our organizations carry the “debt” of these unresolved tensions. Importantly, different individuals process these pressures in a variety of ways. Some people:

can disconnect at the end of a challenging day, month, or quarter. Unless the dissonance threatens their job, they’ll take a certain level of dissonance in stride
internalize that tension. It’s stressful, but they aren’t wired to fight or raise a stink
form alliances and pockets of resistance, and share gripes to blow off steam
serve as spokesperson for the less vocal team members, and take the brunt of the pushback
just up and leave

The important point here is that you wont always see a mass exodus or a big uprising.

These unresolved tensions can hamper an organization for years because the impact is rarely some cataclysmic event that rocks the system at its core. The fed up folks will leave. And those who remain will find a way to coexist, accepting the fact that it isn’t quite safe enough to openly voice their concerns. What permeates is an all too common “low-level dissatisfaction” … people don’t love what is going on, but they don’t hate it enough (or their living situation doesn’t allow) for them to leave.

The irony is that it is these very same people that get called out for being disengaged when the consultants role in.

We direct much attention towards change management. In my experience, the seeds of change are already present in your organization. At some level — typically the level closest to the work — there is an awareness of what is “wrong”. The trick is creating an environment which is safe enough to let those with that awareness speak openly and own a path forward. Without that safety, no amount of process, assistance from consultants, hyping the culture, or empty statements of vision will allow you to turn the corner.

What has worked for you? How do you create this level of safety?

Just a Lifestyle Business …

At a coffee shop somewhere in the Bay Area. Two people are talking about their friend’s business ..

Just a Lifestyle Business …

At a coffee shop somewhere in the Bay Area. Two people are talking about their friend’s business ..

The Atlantic: <http://www.theatlantic.com/technology/archive/2011/02/lets- just-make-the-startup-coffee-shop-thing-official/71603/>

It’s just a lifestyle business for them.

As opposed to?

Something bigger. Something that’ll grow. You know, just more serious.

I don’t know. She really loves the small team vibe and building a great product without the politics.

But that can’t scale! You know that. How are they going to take that to the next level?

What’s the next level? How do you level-up?

Bigger customers. More customers. I mean at some point someone needs to get a return … right? It shows a real lack of ambition if you ask me.

I think they’re doing pretty well actually. And they don’t owe anyone any money.

Exactly. It’s a lifestyle business. It affords her and the team a certain lifestyle. Nothing more. Do you see the pictures on Facebook of her on vacation and stuff? It’s for that. That’s a lifestyle.

You mean, it doesn’t consume your life? Isn’t playing the startup game a lifestyle decision? Look at all of these people in this cafe talking about pivots, exits, and disruption. This sort of seems like a lifestyle.

It’ll only go far! What’s the most she’ll ever pocket … a couple million? (Turns to eye the people walking into the cafe)

I think they’ve done studies on this. I’m not sure you’re happier after $100k a year (or something close to that). She legitimately enjoys showing up, working with the team, and building something people enjoy using. It’s like a group of craftsmen. Or a really good auto-shop or something.

Exactly! Those are LOCAL businesses. Come on, you know what we’re talking about. The SHOW. The GAME! Do you know how much [ — — — ] grew last quarter? That is SICK! That’s leverage …

How will that actually help the majority of people at [ — — —] ? Three years from now when they’ve been acquihired, management turns over, and they’ve pivoted six times … what will it all mean? And point of note … there are three doctor’s offices within a mile from here that have more revenue than half of the startups you’re “tracking”.

That’s the price of progress. Of growth. Did Google think small?

You could argue that Google figured out how to print money. And they were passionate about something. Just like our friend.

… Look over there. That’s [ — — — ] from [ — — —]. I wonder if they’re doing a deal? I’ve heard some whispers ….

Listen to yourself. This is totally a lifestyle for you!

No it’s not … it’s a passion.

And …

We live in San Francisco. Tell me with a straight face that this isn’t a lifestyle …

Um. I mean I guess it is a “way of life”

And …

OK. It’s a lifestyle.

So it is all a lifestyle choice. There you go.

Focus on These 8 Things to Build Better Products

If you focus on these eight concepts you WILL build better products. It will not be easy, and it will not be instant. You’ll probably get a…

Focus on These 8 Things to Build Better Products

If you focus on these eight concepts you WILL build better products. It will not be easy, and it will not be instant. You’ll probably get a lot of pushback and ruffle some feathers, but I promise that your product/service will benefit.

As product development teams we spend a great deal of time looking for “the answer”. We often adopt methodologies as a safety blanket, and then lose faith when the situation changes. Sure, I’ve provided some examples. But your teams are smart! Let them experiment with the how. Paint these broad goals and let them lead you.

Build a better product by …

**1. Shortening the distance between the product development team (UX

and engineering) and the customer**

For example …

Team fieldtrips to visit customers onsite
Biweekly lunch and learns with moderated customer discussion
Allow any front-line team member to pick up phone and call customer
Hire full-time UX researchers, with goal to share research and engage others in research

Why? With each hop you lose signal. Efforts to filter this information to make it more “actionable” are largely ineffective

**2. Accelerating any form of learning about your customers, market,

technology, self, team, and organization**

For example …

Regular team retrospectives, outings, and conversations
Voice-of-customer programs, access to accurate usage metrics, regular presentations on competitors and trends
Pairing, mob-programming, mentor program
Offer experiment-design training, and share results broadly
Celebrate learning! Share broadly. Share visibly

**Why? **Your team’s collective learning is your organization’s foremost asset. Left unshared, it depreciates almost immediately

3. Watching a real user use your product to get their job done

For example …

Moderated and unmoderated usability tests
Diary studies with screen-share (e.g. always-on GoToMeeting study)
Session recording, click-stream analysis

**Why? **To get out of your own head! No use is arguing about whose guess is better

**4. Making it possible to deliver software more fearlessly and with

less drama**

For example …

Test driven development, automated testing, CI, “stop the line” mandate (with no repercussions)
Feature flags, beta groups, prototype framework
Invest in DevOps

Why? If you work scared, you’ll take no risks

5. Reducing the number of dependencies and constraints

For example …

SOA, plan for obsolescence and change vs. hardening and future-proofing
Teams aligned around distinct value streams vs. organized around architecture or skill-sets
Fewer promises to customers, and other stakeholders (internal and external)
Late binding of teams (vs. pre-assigning epics to teams months in advance)
Just-in-time planning, co-design, design sprints, etc.

Why? You can’t move quickly with your hands tied. And if you try, you’ll have mediocre results

6. Promoting diversity, and engaging the minority viewpoint

For example …

Diverse hiring teams, self-selecting teams and projects, voluntary team rotation
Tailor activities to different communication and learning styles
Leaders speak last. Coach on listening and communication skills (while respecting diversity)
Anonymous surveys (if safety level is low)
Ritual dissent

Why? If everyone thinks the same and is forced to agree with the loudest voice, you’ll never explore different perspectives.

7. Fostering creativity and freedom to explore and experiment

For example …

Describe the end-goal vs. a particular solution. In other words, promote creative solutions for “normal” work
Teams self-select stretch innovation project after completing “normal” feature
Get individuals out of functional silo (UXers code, engineers design)
10% time, idea marketplaces (Tinder for collaborating on projects), co-design with customers

Why: If you are 100% delivery focused, you’ll eventually hit the point when the luck runs out. We all crave a sense of impact and get a buzz from trying something new. Bonus: this is how you innovate … not some lab or hack day.

8. Bridging silos

For example …

All employees spend time in support queue
Marketing and sales engaged in group design activities
Front-line teams present to senior management (not a middle-person)

Why: Silos inhibit the flow of information.

That B2B SaaS Savvy Thing

I have received a lot of questions about a graphic I posted on Twitter recently:

That B2B SaaS Savvy Thing

I have received a lot of questions about a graphic I posted on Twitter recently:

Let me explain it in more depth.

Product personas often feature some version of the “savviness” scale. The idea is pretty simple: some humans are skilled at [insert competency here], and others are not. An accounting product might feature:

Accounting savvy
Technical savvy
Management savvy

The challenge is as follows. Product and UX are acutely aware that it is difficult to build a product for users with different savviness levels. But it can be tough to line up the organization around that conviction, especially in the light of mixed messages from the market.

Prospects with **low savvy **can be relatively easy to sell to and close. They feel the pain acutely, but are less demanding and selective. The trouble arrises when you try to make these customers successful with the product. Let’s say you lack exercise savvy and are rapidly gaining weight. You’ll be easily persuaded to join a gym (high perceived product value). But you’ll need constant monitoring, coaching, and coaxing (low ability to be successful with product). Confoundingly, this has nothing to do with budget. Some of the biggest deals come from the least savvy prospects.

Medium savvy customers are a mysterious bunch. They’re aware enough to know what’s possible, and shop more aggressively. The RFP magically grows in scope as they eagerly pile on feature requirements. When I worked at a bike store we joked that the “moderately informed” customer was the toughest to sell and please. But once you got them on a good bike (and put to rest their misguided assumptions) they had the most fun! So they may initially see low perceived value in the product, but have the most to gain in their **ability to be successful **with the product.

High savvy customers, on the other hand, are selective but realistic. They understand the limits of products, and mix-match to achieve their goals. For example, I am a savvy user of analytics tools. Yes I’m somewhat finicky about features, but I know that you need a quiver of tools to do the best job, and that there is often no one right way. I’m able to extract a lot of value out of products, but in so doing they become somewhat interchangeable. The delta from perceived value to actual value is diminished compared to the medium savvy user.

The takeaways is that the behavioral traits that might predict a sale are often not the same traits that will indicate the ability for a customer to thrive using your product. This isn’t to imply that targeting less savvy users is a bad idea but rather that _trying to target all three is a bad idea _(unless you’ve truly nailed one, and are ready to branch out). Even if the sales are rolling in. Someone (usually customer success, customer support, or product) will feel the sting.

You need to target the same persona with intent across the full customer journey including marketing, sales, on-boarding, product, and customers success. They’re unique, and each require a unique approach. Don’t silo the persona building activity inside the product team. Extend it across the whole organization, and align around that vision.

44 Signs You Are Becoming a “Real” PM/PO

How do you know you’re on your way to earning your PM/PO wings? What signals progress? Your first release? Getting “certified” ? Putting…

44 Signs You Are Becoming a “Real” PM/PO

How do you know you’re on your way to earning your PM/PO wings? What signals progress? Your first release? Getting “certified” ? Putting together a pretty roadmap?

No …

You’ll feel like you are annoying the crap out of your team
You’ll find yourself sheepishly asking for an estimate
You’ll realize that estimates are worthless, but still be pressured for a “rough sense of timeframe”
You’ll struggle to explain why your intuition is valid (and be right)
You’ll struggle to explain why your intuition is valid (and be wrong)
You’ll be pressured to ship something before it’s ready
You’ll try to make something perfect when you should have shipped it months ago
You’ll face the harsh reality of a usability test
You’ll put together the best roadmap in the world, and get everyone to buy-in, and then everything will change in an instant
You’ll forget a seemingly trivial detail that will cause a massive delay
You’ll rabbit hole on a seemingly important detail that will cause a massive delay for no apparent customer value
You’ll be blamed for being too solution focused
You’ll be blamed for being too high level
You’ll find out that a new competitor is killing it
You’ll have to break crappy news to your team (often admitting that you’re to blame)
You’ll be jealous about ___________ and how they do product (and be reminded of that fact because they incessently blog about it)
You’ll fancy yourself as technical but be humbled daily
You’ll fancy yourself as UX-savvy but be humbled daily
You’ll fancy yourself as business-savvy but be humbled daily
You’ll say “my team”, but feel oddly distant from your team
You’ll be worried about “distracting” your team, and find yourself not being transparent. And this will come back to haunt you
You’ll find yourself parroting something engineers told you, and realize just how little you understand
You’ll be asked to make your backlog / roadmap more visible, but then be derided when you shift things around
You’ll have a day filled with meetings, and realize you added absolutely no value
You’ll run a great meeting, and no one will notice
You’ll work up a full-fledged wireframe, and then try to tell your UX team member that you don’t have a design in mind
You’ll ship a dud feature that no one uses
You’ll ship an awesome feature that no one even notices
You’ll have to implement an exec’s idea, and know it sucks. And then have to live through the success theater that accompanies the release of said idea
You’ll try to follow up on the impact of shipped features, but get overwhelmed by the next batch
You’ll want to pull your hair out listening to your team debate the technical merits of two, almost identical approaches
You’ll advocate for your pet solution against an almost identical team proposed approach
You’ll tell a customer “it’s on the roadmap” and hear them laugh out loud
You’ll say “No” to something just to prove to yourself that you have some influence and a point of view, and then realize that doing that is stupid
You’ll say “Yes” to a customer in a moment of pure delusion, and then find yourself stubbornly trying to defend a feature that only they will use
You’ll hear that you are not technical enough for the role
You’ll hear that you are too technical for the role, and lack the soft skills
You’ll go to a conference and learn about Lean Startup, and then come back to work and realize that the word hypothesis scares the shit out of people
You’ll be the single wringable neck
You’ll find yourself running cover for your team
You’ll find yourself cursing your team under your breath
You’ll be “empowered” on paper, but find yourself taking orders
You’ll catch yourself giving orders, and learn to empower your team instead
You’ll think you’ve learned from your mistakes, and you’ll magically make them again (just to make sure the learning is ingrained)

…. Because being a PO/PM is hard! It’s humbling, demanding, weird, nebulous, and ever-changing. You’re going to screw up! Accepting that is one of the significant hurdles of becoming a better PM. You’ll figure out how little you know and how little power you have, only to be reminded that it is often the little things that count.

The key is never to stop being humble, empathetic, and curious. Don’t be afraid to discuss your needs and challenges with your team. Be human! And resist the slippery slope to burnout, egotism / mini-CEOism / backlog- ownerism, political gamesmanship, and perpetual mistrust.

Start with your own Why. What do you care about? How do you want to work with the people around you? Answer those questions and the rest will fall into place.

— — — — — — — -

As an aside, I have been doing a 100 day doodle challenge. Some of the doodles are funny because they speak to my impending fears for the day as a product manager:

7 Product Manager / Product Owner Archetypes

Note: PMP is a project management certification

7 Product Manager / Product Owner Archetypes

Note: PMP is a project management certification

Be the Laziest Team and Win

I often challenge teams with the following question:

Be the Laziest Team and Win

I often challenge teams with the following question:

What would happen if you stopped building anything new? Just stopped? Killed the backlogs and roadmaps? Burned it down? Acted like a stubborn mule?

HERMANN G. SIMON — The Stubborn Mule (1881)

Try asking!

Someone is usually quick to say “we’d lose our jobs” (which is likely true given how most orgs work), but after the nervous laughing subsides the conversation gets interesting. Invariably, when pushed, a brave soul will come forward and say “you know, I’m not sure things will change all that much!”

Blasphemy! Make, build, grow, get things done, check things off, and stay busy. It’s who we are, right? There’s always room for another lawn gnome …

Engineers are “resources” that must be “fully utilized” and kept from being “idle”. “What would we do all day? Just sit around and refactor the code, tool up, and knock out bugs?” Keep the line rolling …

1937 Ford Assembly Line

Continue the thought experiment. If you were to stop shipping new stuff, WHAT would happen and WHEN would it happen ? Would you miss a sales goal or growth goal? Would churn increase? Would the competition trounce you? And how do you know?

Pretty quickly you will get to the crux of the matter. And often you’ll discover that building more stuff isn’t necessarily the only way to solve the problem.

The irony is that we disincentivize our front-line resources — often the one’s who know best — from asking these questions. Their job descriptions don’t read “push back on adding ANY new complexity to the product unless we have demonstrated that the value is a massive multiple of costs.” Instead, most organizations and individuals celebrate output over outcomes, and shipping over validating. Try revisiting your release notes from a couple of quarters ago? What happened? Do you even remember what you shipped?

If we have so many ideas … then some of them MUST be good.

<http://saralouhicks.com/how-we-published-our-product-roadmap-to-the-world- using-google-sheets-as-our-cms/>

In a weird form of Parkinson’s Law, teams are invariably able to fill the backlog with ideas that seem reasonably valuable (or at least valuable in comparison to each other). There’s always some new magic bullet to build or table stakes addition. Ideas are cheap. The items are stacked back to back with little opportunity to validate outcomes delivered.

Why is leaving marginally validated new stuff in the product so harmful? It’s super expensive!

Shipping new stuff creates instant debt beyond the resources consumed for the initial build (which — while diligently estimated and obsessed over — often comprise a small % of the overall cost). You’re in the red immediately. You’ve got to service it, maintain it, sell it, market it, and document it. It limits your turning radius. Take your engineering costs and multiply it by 10 (and then charge regular interest) to get a better idea of the outcomes you must deliver to make it all worth it.

Why would you ever want to leave those features in the product?

So try the thought experiment with your team. What would happen if the default stance was to continuously work down debt (UX, technical, etc.), and to test rigorously, and in most cases kill, new ideas? What if the rallying call was efficacy and not efficiency or velocity? What if you encouraged people to do the least amount of building necessary to achieve the required outcomes?

Try asking the question:

What would happen if you were very stubborn about adding anything new?

35 B2B SaaS Tips and Gentle Reminders

The desire for safety stands against every great and noble enterprise — Tacitus

35 B2B SaaS Tips and Gentle Reminders

The desire for safety stands against every great and noble enterprise — Tacitus

The second mouse gets the cheese! — Terry Pratchett

It’s a listicle kind of night. And the topic is B2B Saas!

The broader the product, and the more pains it promises to address, the “easier” it will be to sell. It’s like casting a larger net, or putting on a buffet.
The breadth of a product has an exponential impact on product complexity, cost to service, cost to market, cost to sell, and cost to remain agile
The broader the product, and the more diverse the customer population, the harder it will be to innovate in such a way as to keep all customers happy
A product that can be used to achieve a goal for savvy customers is not the same as a product that delivers that outcome to all customers
Early deals/customers bought into the dream and got lots of love. Their churn and retention rates are not representative
It is virtually impossible to think clearly when considering the true costs and rewards of building a feature to close a deal. But sometimes it works out
Can you hire a reasonably smart 24-year-old, without a Rolodex, and have them close quality deals in 4–6 months? Test that out
At some point, you’ll have a quarter that invites the skeletons out of the closet. You can soften this blow if you keep your ears to the ground and listen to the front-lines
Sales indicate you’ve discovered a pain worth solving. Usage and renewal indicate that your product solves that pain
No news is not good news. Welcome the feature requests, blistering feedback, and support tickets (to a point). It shows someone is taking notice
Rapid growth and learning aren’t always great bedfellows. Resist the urge to lock down structures, processes, comp plans, or pricing to the point that you stop experimenting
Doubling the size of your team does not make it 2x more efficient OR effective
Be diligent about calculating your cost of acquisition (CAC). What was involved in closing the deal? Who was involved?
Will someone take you to their next job? That’s an excellent sign
In the case of a highly aspirational product, don’t be too critical of churn. Sometimes it just isn’t a great fit, and that’s OK.
You can explain NPS away. But the reality remains
Beware of the platform trap. Yes, you will draw in prospects who wanted everything “all in one place”. Can you deliver that better than a selection of best in breed products?
Have a reason to exist beyond growing, and meeting quotas. Those are things required to realize your higher mission, not an end unto themselves
Keep a tab on sales and support heroics. The goal is to make that not necessary rather than making it commonplace. Those early hires get tired!
Demonstrating ROI is a product mandate, not just something you put in your sales presentations. If you aren’t producing results and outcomes, it will eventually come back to haunt you
If the customer was not actively using the competitor’s product, then it’s likely that they weren’t your competitor. You didn’t displace them. The same forces (the status quo in their organization) will also challenge usage of your product
Customers expect startups to innovate/expand their product. That’s part of the reason for buying. Couple that with founders selling, and you’ll have big shoes to fill down the road
In many domains (e.g. analytics, AR, machine learning, mobile, etc.) you’ll get a lot of experimental budgets thrown your way. Differentiating between experimental budget and real budget can be difficult
Understand why each customer purchased your product. The “real” why even if it doesn’t fit into a neat box on a spreadsheet
Hopefully, using your product will inspire your customers. But if you haven’t addressed their use case lately, it may encourage them to replace you now they’ve figured out what outcomes they can drive
Keep a watch out for the non-competitor who is learning from all of your mistakes, and all of your progress. Especially if they have a lot more money
Low total cost of ownership (TCO) is a double-edged sword. Without skin in the game, it can be difficult to differentiate experimentation from commitment
Keep things simple! It is tempting to think you’ve expanded your ability to do multiple things at once. The reality is that things are still changing quickly and that you’re likely still in learning mode (vs. execution mode)
When trying to understand value, look for a benchmark purchase in the organization. How much do they spend on coffee, lunches, and onboarding their new employees?
It’s almost always easier to go upmarket with a validated product than it is to target SMBs after pursuing “enterprise” sized deals
Watch out for having too many cooks in the kitchen. Especially experienced cooks. You’ll have to say no to 95% of your good ideas, even if they don’t involve engineering, and that can be hard for folks who know the “right” things to do
Beware of strong relationship selling. If you’re a sales ninja, it can be relatively easy to persuade someone to buy. Ask how you’ll make that customer successful, and whether you have other customers that look just like this customer
The word “enterprise” is often misleading. There are plenty of companies who will pay enterprise amounts, but who don’t require an enterprise sales approach
Watch for the invisible costs of your current approach, and try to anticipate when you’ll need to pay off the interest (and at what rate). Carrying technical, UX, team culture, or learning debt will eventually need to be paid off. When?
Look at your marketing and messaging. If you keep waffling between multiple messages and pitches, ask yourself why that is happening. Schizophrenic product? Too broad? Broad on purpose?

5 Simple Questions to Drive Validated Learning

Here is a simple model that frames product development as an effort to trigger a change in user behavior. It is accessible and not too jargon-laden. It can be used to describe things on the highest level — a whole business, for example — or a specific, low-level design change.

Whose behavior will change because of the work?

Our product development efforts target people who share some common traits and characteristics. What are those traits and characteristics, and who are the people that meet those traits and characteristics?

Example: Customer Service Reps (CSRs) at technology savvy companies and their Customers.

What is their current behavior?

What pattern of behavior are we hoping to change? This behavior can be extremely specific — like a particular navigation flow or interaction — or it can be very broad like purchasing habits, lifestyle choices, or major life decisions. How often does it happen? How ingrained is the behavior? How does the Target benefit from the existing behavior, or at a minimum put up with it?

Example: Customers currently submit cases via an online form, and then wait up to 24hrs for a reply. The CSRs currently monitor a case queue and communicate with Customers using email and on rare occasions, the phone. The VP of CS believes that opening up a direct channel will overwhelm the team and may not provide them flexibility in responding to case volume.

How will their behavior change?

Something will change as a result of our intervention. Will the user start or stop doing a particular activity? Will they do something more or less often? Will their outlook change? Will they give you more money and your competitors less money? Will they use your impressive new search feature instead of spending time navigating the tab structure?

Example: Customers will use a communication channel “in-app” that resembles a chat interface instead of using the online case submission forms. They’ll feel comfortable interacting with a rep via chat. CSRs will respond to these in-app messages as if they were virtual telephone calls (and do so immediately, personably, and directly).

How will we intervene?

In the example above, the behavior change actually includes the proposed Intervention (in-app chat). The intervention might be a change in design, a change in tactics, or a change in in packaging, messaging, or technology. We’re mixing the pot in some way and hopefully something will happen.

Example: A new online home selling platform triggers a Target who previously would only sell using a broker to take on the task of selling their own house, and to fork over a fixed fee of $2,000. The Intervention is a virtual coach that adapts advice to local and regional requirements for home selling.

How will the new behavior benefit the user/business?

The behavior change must result in some benefit for it to “stick”. Without a significant payoff, you’ll be hard-pressed to persuade someone to change their mindset and habits. Big payoffs can reinforce significant behavior changes (like paying your company a lot more money). The benefit is the return on investment, where the investment is some shift from the status quo.

Example: Customers will enjoy the personal touch. CSRs will deliver faster customer service without the hassle of a phone conversation. The CSR’s employer will have higher customer retention while keeping their CSR budget reasonably small.

Validated Learning

In the spirit of validated learning, we attempt to validate the various assumptions — explicit and implicit — in the framework:

The Target exists, and can be isolated and targeted consistently
The Target’s current behavior exists, and can be measured and understood
We can change the Target’s behavior with our Intervention
We can measure and understand their new behavior
The new behavior triggers a benefit (Outcome) for the Target
The Target values the Outcome sufficiently to change their behavior permanently

In most cases, just validating one piece of the puzzle (the Outcome for example) is not sufficient. You need the full picture. And it is easy to get bogged down in the weeds — a particular intervention, for example — and lost sight of the major benefits required to really change the ballgame.

Innovation

Additionally, on a high level we can also use this framework to understand the various types of innovation. Some examples:

Discovering new and underserved Targets
Address the needs of a large Target with a small behavior change and a small, but proportionately valuable benefit
Address the needs of a narrow Target with a large behavior change and large benefit
Figure out how to create a better outcome without significantly changing someone’s behavior
Figure out how to trigger significant behavioral changes that result in a big benefit

Innovation changes one or more parts of the equation in new and novel ways.

And that’s that. Talk these questions over with your team, and prioritize your product development efforts to successively validate the various parts of the framework.

Chasing Revenue Growth (and Hidden Costs)

I am an avid cyclist, and have also had the privilege of coaching a couple of talented bike racers.

Chasing Revenue Growth (and Hidden Costs)

I am an avid cyclist, and have also had the privilege of coaching a couple of talented bike racers.

One approach to assessing an athlete (not my preferred strategy) is to set a schedule of ever-increasing training loads. The idea is that the athlete will eventually hit the wall and that you will have established their upper bounds for withstanding the training stress. This approach is similar to a venture capital firm setting a ramped ladder of revenue targets. They expect some of their portfolio companies to “hit the wall” and “crash and burn”, but that’s just how the cookie crumbles.

The danger here — as with startups — is that a highly motivated person can usually find a way. We are incredibly adaptable, and can push ourselves for many, many months. Overtraining doesn’t creep up linearly. I’ve had cyclist friends dig a hole for years before it caught up with them. The onslaught of fatigue and poor motivation was sudden, and there was no quick fix. It didn’t mean they were untalented cyclists. On the contrary, they tended to be the most talented (and most motivated).

<https://statumentis.wordpress.com/2014/12/01/overtraining-is-of-great- importance-to-the-high-performance-athlete-we-need-to-gain-knowledge/>

Usually, there was some part of the formula that was a bit off. And being truly motivated and hell-bent athletes, they just “pushed through”. The tragedy is that some of these people quit!

To build a long term career (either amateur or professional) the athlete must master:

Diet
Recovery
Mindset and psychology
A strong support structure
Event selection and specialization

http://www.pezcyclingnews.com/latestnews/toolbox-jump-in-the-waters-great/

These things take time and commitment to perfect. You can get “decently far” without paying too much attention to them, but eventually, you’ll have to pay off the debt. For growing startups, you have similar “skills”:

Leadership skills
Ability to attract and retain the best talent
Strong, resilient culture
Agility
Software quality and extensibility
Managing growing system complexity
Alignment and a sense of purpose
Product and UX savvy
High customer satisfaction

As with diet, stress management, and positive psychology, none of these things behave in a linear fashion. You don’t get a lot of notice before the hammer drops. When you hit that bad quarter, you won’t just be able to do first-aid. You will spend a long time paying the price.

The alternative approach is to make these supporting skills first-class citizens. The athlete “trains” their diet, recovery, and psychology. We extend time horizons to ensure that the system is healthy and that they’ll be prepared. We don’t push until we hit (and exceed) the limit, but rather creep up on the limit paying very close attention to the warning signs.

If you’re involved in this Darwinian revenue goal game, try to assess the fitness of your business on a deeper level. Conduct a pre-mortem activity and visualize your first crappy quarter. What happened? And what can you do about it now? I frequently hear VCs say something like:

Well, it’s easy to get to ___________ . Wait until they try to get from ____ to _____

The underlying assumption here is that passing these hurdles validates your business. It may, but it doesn’t necessarily validate the full health of your venture. The ability to right the ship will be highly constrained if you wait for a problem to manifest. Look for those early signs!

The Tease

Find and fix The Tease to keep your best team members

Fix The Tease (Turning Your Org to 11)

Find and fix The Tease to keep your best team members

The Tease is real. And it lurks almost exclusively in some of the best organizations.

http://909sickle.net/hidden/somethings-not-right

Imagine you are so close to something great. You’ve got all of the raw materials: the talent, the drive, and the passion. It’s right there for you to grab. Just reach for it!

Your organization is saying all the right things. You are empowered. The cultural manifesto is in place. People use words like “servant leadership”, “autonomy”, “cross-functional teams”, “experiment-friendly”, and “safe to fail”. By all measures your company “gets it”. Just reach for it!

Imagine a single black sunflower in a bed of yellow sunflowers. Or a trickle of sewage into a pristine mountain stream. Or the person having a loud cell- phone conversation on a quiet bus. You notice. It grates on you. In another setting, it would be normal. But here it isn’t.

This is The Tease. The Tease is when you’re so close to something awesome. All the pieces are in place. But there is a trickle of suck. There’s some dissonance, incongruity, or poison lurking. Not enough to head for the hills, but just enough for it to linger in the collective organizational consciousness. It’s the dab of politics, silos, favoritism, dysfunction, or accepted bad behavior. The fact that the organization is so excellent otherwise causes the sting.

Somehow “everywhere has problems” is no solace. You’re a victim of your considerable efforts elsewhere. By making 99% of things awesome, and letting that 1% suck, you let that 1% get magnified. It’s the loud wedding guest interrupting the nuptials at an awesome wedding. That’s what people remember …

You attract the best and the best notice The Tease. Find and fix The Tease. It won’t be easy — the fact that it persists inside an awesome organization is the testament to its power — but you must fix it to retain your best talent.

How do you identify The Tease? Just listen for it … you’ve probably already heard about it. Better yet, figure out why your organization can’t “self repair” to fix The Tease. Remove that blocker, and the rest will happen naturally.

Pain, Potential, and Outcomes

Eat healthy! Get in shape! All your data in one place! Faster time to market! Stop the information overload! Uptime! Speed! Less busywork…

Pain, Potential, and Outcomes

Eat healthy! Get in shape! All your data in one place! Faster time to market! Stop the information overload! Uptime! Speed! Less busywork! Happier customers! Lower churn! More with less! More revenue! Lower costs!

Can you relate? Sure. Are there thousands (maybe tens of thousands) of startups trying to solve those pains? Yes.

It all starts with pain (latent, expressed, or otherwise). You won’t get things into 2nd gear unless someone cares. And then potential. What you have — your product or service — has to at least hint at the possibility of solving that pain. And finally, an outcome. The product uniquely, affordably, and gracefully alleviates your pain. There’s return on investment.

It doesn’t always go as planned.

Example. I want clean water. I don’t want crap in my water. Pain!
My goodness, the Brita water filter looks amazingly clear, crisp, and pure. Potential!
Damn, they never told me about these filters, and the charcoal, and how I’m a lazy person who can’t be bothered to clean the thing, or remember to buy the filters. Outcome? No.

The temptation when validating your startup is to stop at Pain and Potential. Pain and potential can get you pretty far when prospects are looking for an edge. It can feel exhilarating. You can grow quickly on pain and potential. A pain with an alluring product offering can attract a broad cross-section of people, especially if you’ve got a good sales team.

But at the end of the day, it’ll be the competitor that produces Outcomes (and keeps costs in line with the degree of differentiation) that will win the day. You absolutely must know whether the potential promised in your product is delivering an outcome. I always say…

Sales and marketing sell the pain and the potential. Product delivers on that promise

You could broadly divide up “sales driven” and “product driven” startups by how they approach this sequence:

The sales driven startup puts energy behind selling the pain and potential. Growth is the first objective. After going broad and taking stock of customer outcomes, they’ll attempt to Focus.

The product driven startup validates Outcomes first, Focuses based on those learnings, and then attempts Growth.

The bootstrapped startup has to achieve some level of profitability early to keep the lights on, then must chase Outcomes to validate their offering as quickly as possible, and then move on to Focus based on that knowledge and Grow.

Regardless of the approach, you’ll need to consider outcomes eventually.

Does your product uniquely, affordably, and gracefully alleviates the customer pain? Your product is not a list of features. It’s a vehicle to create outcomes.

Feature bullets sell the product. Your product delivers the outcomes.

The Evolving Product Manager Role

Where is Product Management going? What do the “best” do differently?

The Evolving Product Manager Role

Where is Product Management going? What do the “best” do differently?

Here are the trends I see in forward thinking product development teams:

company culture is…

What you say, and how often you say it

company culture is…

What you say, and how often you say it
What, when, and how you celebrate
The losses and missteps you acknowledge, and how you respond
How you behave when the chips are down
What you fight for at all costs
The corners you cut
Who you hire, promote, and compensate, and who you fire
Who you “smoke out” until they leave the organization
The worst behavior you accept and the best behavior you reject
The voices you amplify, and the voices you suppress
When you encourage conformity, and when you promote diversity
How you handle disagreements and differences in opinion
How and where you spend your time and money
What gets discussed at the water cooler
What gets discussed out in the open, and behind closed doors
The contradictions you allow and the contradictions you stamp out
The exceptions you make and the things that never budge
Who sits together and how you arrange your office
Who gets access to the best tools, technology, and infrastructure
What you say about your customers during challenging situations

Beat the Feature Factory: Run Pre-cap Design Studios

Recommendation: Commit to a future recap of your product development initiative, and design the slides early in the process (leaving…

Beat the Feature Factory: Run Pre-cap Design Studios

Recommendation:_ Commit to a future recap of your product development initiative, and design the slides early in the process (leaving placeholders for the actual data)_

Benefit:_ Promote a learning mindset. Balance upfront planning with unbiased retrospective. Crease a sense of team ownership and pride. Drive a shared understanding of the initiative. Promote evidence driven development, even when the current strategy is more tilted towards the “feature factory”._

The Opportunity

I’ve always enjoyed exercises like [premortems](http://quickbase.intuit.com/blog/make-better-decisions-by- conducting-pre-mortems), [future backwards](http://cognitive-edge.com/methods /the-future-backwards/), and [heaven and hell](http://blog.agilar.org/2015/05/07/retrospectives-series-heaven-and- hell/). These activities are great for exploring potential futures for an initiative, and using that information to guide the plan and approach. I was conducting a pre-mortem recently, and a senior engineer said something that hit me like a brick:

You know… when this is “done”, we will have moved on to the next thing. Sure we will have shipped something, but it will be anyone’s guess whether this actually worked. When do we answer that question? It just never seems to happen.

I thought about this for a while. She was right.

We had done a half-dozen activities exploring catastrophic outcomes, heavenly future states, problem definition, problem exploration, and possible solutions. There was a “great deck” with an inspiring vision and lots of broad context. But the reality was that her team would be cycled on to new efforts before they had a chance to validate the expected impact. It was the epitome of upfront planning — not adaptive planning — and that sucked.

Those activities are great, but they are still front-loaded. I tentatively offered the following thought exercise:

It is three months after shipping. You may have moved on to something else, but you’re eager to figure out if this worked and that it drove the expected results. It’s nagging you. You’re curious. You schedule a talk to the whole engineering team (100+ individuals) to share your learnings. What do you present?

I figured an intermediate step would be simply committing to compare the expected outcome to the actual outcome.

Something about this proposal clicked with the team. It had the effect of putting a stake in the ground. It was a commitment to learning, and presenting those learnings in public…not just when and if someone had time to “pull the numbers”. Summary: it worked. The approach caught on and upped the whole team’s game.

General Outline

Below I’ve provided a basic outline for the presentation. It’s nothing fancy, but you’d be amazed at how infrequently these types of presentations happen unless there’s a major win to promote. Learnings are rarely celebrated, and that is a shame.

Tips:

Get executive buy-in for the retrospective, and schedule it early. Part of what makes this work is the excitement (and pressure) of presenting to the whole team
Use a design studio approach to “design” the slides. This alone is a great exercise for driving a shared understanding of the problem to solve. Whenever possible do it with the whole team
Use actual numbers whenever possible, but don’t be afraid to tell good stories
You might need to arrange a data-foraging exercise to pull this together, but it won’t be in vain. Self-promotion alert … you might consider Pendo (my current product) which makes it easy to pull retroactive data without manual tagging and instrumentation.
Iterate on the deck while the effort is in progress, but don’t rewrite history. What makes these presentations awesome is the narrative. It sets a great example for the team.
Encourage the team to present as a group. It will be more impactful that way

Conclusion

Let me know how this works for you! In my experience, visual brainstorming works. Light peer pressure works. And face-to-face sharing inspires. Give it a try and feel free to ask any questions in the comments below.

Complexity Is a Startup Killer. Don’t Grow Up

Complexity is a startup killer. Like a giant anchor, it slows you down until you’ve lost the only two advantages a startup will have: speed…

Complexity Is a Startup Killer. Don’t Grow Up

Complexity is a startup killer. Like a giant anchor, it slows you down until you’ve lost the only two advantages a startup will have: speed and focus.

Credit: AMC (The Prisoner)

Complexity manifests when you target multiple jobs-to-be- done, [elephant hunt](https://bothsidesofthetable.com /most-startups-should-be-deer-hunters-7fdecf58f4f6#.4h29ypz1l), scale up, hire quickly, cut corners, and implement too many “good ideas” (which seem to ooze from every pore). The impact is exponential as you add more fuel (people, experienced people in particular) to the fire. Before you know it, no one knows what’s going on.

We’re not talking an [autonomous ant colony](http://www.techtimes.com/articles/7677/20140530/ants-have-a-more- complex-network-than-google.htm) here. Nor are we talking about a Company like Spotify or Intuit with its dozens of pod-like [squads](https://rctom.hbs.org/submission/the-spotify-squad-how-to- successfully-lead-a-global-organization-without-an-operations-team/), guilds, and colleges. When you’re further along in your business — or have evolved since the mid-Cretaceous period — you can start to divide and conquer. With a startup, you are none of those things. You’re still building, measuring, and learning. Anything that constrains that is an antipattern.

**Brazil **(1985) — Director: Terry Gilliam

The problem here is that complexity is incredibly tempting to add! Let features reproduce. Get the contract management tool. Scale up sales. Close the deal. Pitch the next product enhancement. Add more people to your board. Find partnerships. Say Yes. Hire “experienced” people (in quotes because Company experience doesn’t equate to Startup experience). We’re eager, and there are a full 24hrs in the day. And you’ve always got those “good ideas”…

In creeps the complexity like a thick fog over the Sunset District. But the fog almost never clears. Once you’ve gone down the rabbit hole, it is nearly impossible to come back up for air.

<http://sfcitizen.com/blog/2015/02/16/ah-the-sunset-district-home-of-chain- stores-unreliable-transit-and-oppressive-fog/>

Startups always flirt with a chaotic, existential breakdown. You’re on the precipice, even if you don’t know it. Complexity is a safety blanket. It feels and smells like momentum. The opposite — keeping it raw and focused — is scary as shit. And it looks nothing like Company work.

But you NEED to fight to resist complexity, even if it freaks you out. Not in the problem space — for sure, chase after complex challenges — but in the execution and organizational space. Keep things so small, nimble, and simple that it causes you near term pain (imagine you’re smelling your favorite dish in the world and have to walk away). Don’t be a mini version of a Company. You’ll have plenty of time to grow up.

Startups: Be Awesome At Something

Quick post to get back in the swing of things after a much needed vacation.

Startups: Be Awesome At Something

Quick post to get back in the swing of things after a much needed vacation.

When I talk to startup product development teams, I listen carefully for people saying things like:

We’re real __________________ nerds
We are experts at __________________
We live and breath __________________
Our team’s secret weapon is __________________
We consistently find a way to __________________
At the core, we’re here today because __________________

If I hear people provide specific, non-plastic responses, my ears perk up.

Luck, first-mover advantage, funding, and connections can get you pretty far. But to win (and continue winning) you need to be awesome at _something. _That something can be a variety of things—networking, raising money, technical/ux/product chops, knowledge of a certain buyer pain, marketing creativity, etc. — but it needs to be repeatable and intentional.

Startups often fall into these traps:

They’re scattered: they want_ _to be awesome at everything
They’re conflicted: they try to be awesome at things which are in direct opposition
They’re delusional: they make bold, aspirational claims about things that they aren’t, frankly, awesome at
They’re myopic: they make big bets on being awesome at things that don’t really matter, and don’t give them an edge
They’re self-conscious: they don’t want to admit what they’re actually good at because it isn’t sexy, “cutting edge”, etc.

These traps lead you down a slippery slope: ignoring and failing to double down on what you’re actually good at and failing to become awesome at what you need to be awesome at.

So, take a moment to answer:

What must we be awesome at?

What are we awesome at?

10 Things I Learned By Doodling For 100 Days Straight

I recently finished a 100 day doodle challenge. How did it go?

10 Things I Learned By Doodling For 100 Days Straight

I recently finished a 100 day doodle challenge. How did it go?

The Rules

I set a small number of rules.

One drawing a day for 100 consecutive days. No skipping
Share the drawing on Instagram and Facebook
No erasing, start-overs, tear-outs, whiteout
Don’t overthink. Start drawing within 60 seconds of opening pad
Black and red pen
In one sitting

What I learned …

I spent 100hrs+ “meditating” with a pen. That’s a win. No screens! No typing! No devices! The careful line-work in particular was very calming
Overall my mood and outlook improved
Peer pressure works! Once my friends started chiming in on Facebook I wasn’t turning back. On a couple occasions my challenge inspired others to take the plunge. That was very rewarding and inspiring
The workweek saps your creative energy. It’s hard to focus when you’re stressed. Stress would increase as the week progressed, and the drawings would become increasingly scattered. On Saturday, the relaxation kicked in. I kept thinking … what would it take to make every day like Saturday? And was my work suffering from the same lack of lateral thinking?
Ritual matters. 90% of my drawings were completed at the same coffee place (Raleigh Raw), drinking the same coffee (bullet coffee with grass-fed butter), and having the same smoothie (blueberry). It took 10 days or so to get in the swing of things. And maybe 30 to make it a habit. I’m pretty sure the caffeine injection / timing played some part in this
Tools inspire. Having a good set of pens and a pen bag was a big part of the experience. I have a pen fetish now
It takes practice to turn off your inner critic. Social sharing boosts the need to “make it cool”. Some of the best drawings started with no censorship and forethought. I had to consciously block out the inevitable share and looking for likes and comments.
When you do something every day, it’s ok if it sucks! You have another shot. If it’s your only shot, you’re more prone to freak yourself out
Some days you’ll want to get serious and meaningful. Other days you’ll shoot for trite and flippant. That’s ok! When you have output, you wait patiently for the “good ones”
Constraints help. Limiting myself to mostly black pen let me practice and explore what was possible

The Drawings (In Order)

1:100 This wasn’t too much of a stretch. I draw mind-maps all day. So it was no surprise that I started off in familiar territory.

2: 100 He sure looks scared. And of course there’s the wing-suit which must be a reference to one of my favorite films …. Brazil. Tiny dots make their first appearance, but overall I haven’t found my groove yet.

3:100 Adele! Hello it’s me. Themes of isolation, rain, birds, flying, and tall places predominate. Plus I’m still using words.

4:100 What a smarty pants! Actually, this did start with me imagining the sensation of a rose petals on my eyeballs. This one made me happy. And it was deliberate to some degree so it didn’t feel completely accidental.

5:100 Wordplay continues. I was high from the rose colored glasses, so I took another shot at something witty. At this point I was all in. I had shared the drawings on Facebook. Game on. But it didn’t have the zing of the glasses.

6:100 Major discovery! Starbucks can completely **** me up. My hands were shaking and it felt like lasers were shooting out of my eyeballs. So I drew that.

**7:100 **OK. Things get serious. I remember what NYC looked like shortly after 9/11. I remember all the posters taped up on construction site walls. It was heart breaking. But I have to admit … I questioned whether I was just milking this memory for the drawing. Have you ever had that happen?

**8:100 **My first of the the weird “the people are kind of small and the object is super big” drawings. I also discovered how to draw sand. The father and son walking away held some significance for me. This was the first drawing where I stated to get super anal with the line-work.

9:100 Strange how this happens. Back to back small people (see 8:100). This started as an insect, but I wasn’t happy with it. It didn’t look “right”. So at the last minute I turned it into a kite. I was traveling at the time, so I was likely caffeinated with Starbucks coffee (bad ideas), and my head wasn’t in the game.

10:100 OK! Now we’re in business. The addiction with line-work, different textures, rain clouds, and awkward perspective gazebos begins. I actually finished this at an Agile conference in King of Prussia (of all places). My mind must have been pretty dialed in. I start to notice the fetish of carrying around nice pens.

11:100 Travel day. This felt like weak sauce. It can be hard to string together super-anal line-work on back to back days.

12:100 Strange swirls and flourishes rise! This was one of those wandering “I won’t know until it is almost done” doodles. I go to my old standby little-people (see above) and it comes to life. I loved the idea of a strange ferris / hamster wheel. The buttocks in the lower left was unintentional.

**13:100 **13 was not lucky to me. I get lost in the swirls. This was probably a stressful day.

14:100 Birds! Rain! Sand! Themes unite. My favorite part of this drawing was doing the clouds. I didn’t expect it to work. But in retrospect they look very layered and humid.

15:100 I patted myself on the back a bunch of times for this one. Anal line-work? Check. Word-play? Check. My friend Tim counted them to make sure I did include 50 shades. I did. Pulling this off made my day. I haven’t seen the movie. Is it good?

16:100 Return of the crazy gazebo and little people. There’s some movement here … they’re climbing to the top. What’s at the top? I don’t know. Remember the rocks. I come back to them near the end.

17:100 Stressful morning. I couldn’t get my head in the game here, and work was looming on my mind. Stress muffles the thoughts and saps the patience.

18:100 Regaining some momentum I tap into my childhood obsession with catfish. I considered the return to halfway focused and inspired drawing a win here (given the previous day’s doodle crap).

19:100 Is it a house? A hotel? How about a weird house with stairs? You can see the lines become tighter here. Dots. A wild freeform splat. These themes will return in future drawings.

20:100 And now for something completely different! I was getting bored with the semi-literal stuff. The idea of parallel lines seemed appealing.

21:100 I channel a bracelet designer and go for symmetry.

22:100 This followed the pattern of “ok, let’s draw a bunch of patterns and then position a person in the drawing”. Webs, roses, thorns. Some familiar themes and a more confident larger non-stick-figure.

24:100 A crying elephant in a hall of mirrors with a nude. Makes perfect sense. I came to the elephant about halfway through the doodle.

25:100 A lapse. My mind wasn’t in it and work was piling up the stress. I try to resurrect it a couple ways, but it will be the flying steak forever.

26:100 Patterns and doodles. Some new techniques … little circles, network drawings, a stray bra, and booze.

27:100 More structure and control. For a while I was thinking about making it a woman’s back. Maybe it is. But I resort to a small man on a bicycle underneath a bunch of balloons.

28:100 End of the workweek! Can’t hold it together. Fridays aren’t great doodle days. Note that I repeated #27. This is #28.

29:100 Ah! Saturdays. Time to be incredibly detailed. The steps descend.

30:100 First of the knife drawings. And sexual fruit.

31:100 Must be a Monday. Semi-relaxed but mind buzzing. The squares return in a tree drawing later.

32:100 This was more playful with larger circles. On some level it is related to the prior day’s drawing, but I go big.

33:100 Intriguing. I was thinking about turning 41 years old apparently.

34:100 More knives, fruit, and sex. Replete with a bra and a serpent. What was going on?

35:100 I return to the blocky tree (see 11:100), and scaling extremes (little house or person). But there’s a balance here I like.

36:100 And now for a different tree! This was a good recovery from the prior day. Weekend work for sure.

**37:100 **Robot insect. With crown (or something). I return to this a bit later.

38:100 I really loved this. The bullet coffee actually works. I was in the zone for a while. It was like meditating. I discovered that messy dot work can be effective for contouring things.

39:100 And I lose it! After the joy of the prior day’s work — probably early in the work week — I lose focus. The fish is nice though.

40:100 Light nudity. Lizards. Bikes. Excel cell references. Octopus. Just another day I guess. This fits in the “lots of boxes / circles with little things mixed in” theme.

41:100 This was the first of the “matchstick” type drawings.

42:100 And … with the Cat Save! When in doubt make it a monitor and include a cat. Totally makes sense.

43:100 I was looking at Weather Underground and noticed the wind markers. That seemed like a cool thing to obsessively draw over and over. But I wanted to take a risk … on something “Real”. So I drew an arm and didn’t destroy it. See later for the Sperm Tree. I avoided that effect here.

44:100 Color by numbers?

45:100 Bolstered by my confidence drawing “people”, I tried to sprinkle some people in. Like Nigel Tufnell. And boys. But I’m most proud of the globs on globs.

46:100 Self-portrait. I was in a pretty angst mood that day. I was coming up with a ton of ideas … but all the ideas freaked me out.

47:100 And the hill slopes up to the right! There are birds and rocks. And patterns. And network drawings. Some classic themes with good line-work.

48:100 Why don’t we keep on this network drawing kick? Sure! It even looks like an animal. See later for the nude with tiny networks.

49:100 Weird hotel on a hill. Knives. Patterns!

50:100 Bolstered by my new pen purchases, I go completely ape-shit. There’s blood. And bones. And feathers.

51:100 These pens are great. Seriously, good tools — and having 50 drawings under my belt — made this a ton of fun. The dots, crosshatch, etc.

52:100 I go deep. This started as a network drawing. Incredibly detailed. But it started to take the form of a woman. I was excited. Did the red mess it up?

53:100 Maybe it is fatigue, but I return to something less arduous. I’m pretty sure this was a Monday. After the weekend of new pens and meditation, I go for something less busy.

54:100 As strange as it sounds, the “messy” branches on the upper left were a major win for me. I was really in the line-mode, and broke out of it with some happiness-producing results.

**55:100 **Tunnels? More and more lines, but the “fuzziness” on the tubing was pleasing. It felt less linear.

56:100 Black Lives Matter news. I kept thinking about a person trying to scream, but nothing coming out.

57:100 And then follow that up with a completely unrelated sperm tree. I really didn’t want this to be the sperm tree. I doodled and doodled, and kept hoping it wouldn’t look like a sperm tree. But it ended up that way.

58:100 Shit! That was super lucky. A whale! A real whale. Once the form took shape, I found it hard to turn back. I learned with this drawing that you could also use light pen pressure for the line work. It was more like shading.

59:100 Weekday distraction. Oh well, it must be a vein. Let’s draw arrows to show the disease creeping in.

60:100 Feeling toxic. Like only bullshit is leaving my mouth! Self-portrait again.

**61:100 **One of those days!

62:100 Thicker lines. Petals. Layers. A good reprieve from the day before.

63:100 And we’re back to little gazebos and walkways. Phew.

64:100 Lest we forget trees, little people, fruit, and all of that good stuff.

65:100 Today let’s draw a ton of squares! So I did. There was something challenging about drawing little squares, and not circles.

66:100 Let’s get angular! And draw lines. This is an oft repeated theme, but I went full screen for this picture.

67:100 Non-distinct. Mid week. I finished this at 11:30PM.

68:100 Little critters! In retrospect I didn’t like the fact that the critters were trapped by the tree. Looks uncomfortable.

69:100 No guilt! There was a creative malfunction here. So instead of just phoning it in, I called it out.

70:100 … a hill, up and to the right. Thorns. Apparently (see upper left) I had some to-dos on my mind. This is a facsimile of some earlier drawings (blog rocks).

71:100 Hurray for the weekend! Calm. Serenity. A tiny person, rain, and a tree. But seriously, I enjoyed the layering of the clouds on this one, and the obsessive square drawing. Win! Confidence regained.

72:100 Flexible fly swatters with arms. Of course!

73:100 Back to wordplay. Visited friends in LA. The sun. The West Coast cool. Pulled this off in the LAX lounge over beers, but that’s what you can do when you’re sketching and not drawing lines furiously.

74:100 Look at this thick pen. Patterns! Jet lagged to be honest.

75:100 This makes me angry, actually. It feels very phoned-in. Oh hey, let’s draw a human cat with triangle hair. Nothing feels right about it.

76:100 More distraction. Saving grace is the swimming pool.

77:100 And then faith is restored! Back to some flower-work. Tight lines. Petals. Good recovery.

78:100 I’m not stopping there! Let’s get the line ON! I was calm, caffeinated with good coffee, and ready to experiment (like with the fuzzy bird head). Guess what? It’s a Saturday! Maybe this is the living version of the bird in 50:100.

79:100 And on Sunday I slow down a bit. Softer lines. Post bike ride. Some sinew.

80:100 **** this. I am going to draw Monday a bunch of times. Over and over.

81:100 Good recovery for a Tuesday. Not great. But not totally annoying.

**82:100 **I love great pens. They make Wednesday awesome.

83:100 And this is what a Thursday feels like. Scribble scribble.

84:100 Keep pushing through. You can always fall back on matchsticks, connective lines, quasi-harps, and dark line bursts.

85:100 One continuous line. This one felt like I was just floating along. It probably took a couple hours but I was enjoying my coffee too much. Intestines?

86:100 Down the rabbit (intestine) hole.

87:100 The old bird and talon standby. Blood!

88:100 Remember that robot? 37:100. A gentler robot, with a bearded Grecian head. Makes perfect sense.

89:100 Waaaay different! I set out here to challenge myself with non-lines. This might have been mid-week as well, but the project suited the freneticism of the workweek.

90:100 Completely Kosher. No innuendo at all. It’s a flower.

91:100 The solid branches were a change here. It felt swampy and drippy.

92:100 The goat! This was a serious effort. I worked hard on the line-work. It started to take the shape of these aggressive rocks. It might seem stereotypical — Mountain Goat — but the idea of this goal being challenged by this maze of rocks was appealing.

93:100 Another hotel on a barren landscape. With two crystal balls for eyes. it is almost insect-like, and I was probably shooting for that initially.

94:100 This took on a fishy / kelpy vibe kind of early. But it wasn’t until I committed 100% to the scales that it took shape.

95:100 When in doubt … wait until 11:30PM when you’re fried from work and draw a tree.

96:100 Nice and simple and bursty!

97:100 If you’re a child of divorce (or don’t have kids and use Facebook) you know that feeling of seeing happy families together through a haze/static.

98:100 Life takes you on twists and turns sometimes.

99:100 First full day in Greece on Vacation! I was super proud of the ink-painting on this one. It took a couple hours. But it captured my sense of calm and contemplation.

100:100 What’s next? Who knows!

Agile: Don’t Exchange Waterfalls for Whirlpools

This is a waterfall:

Agile: Don’t Exchange Waterfalls for Whirlpools

This is a waterfall:

In the Agile product development world, waterfalls are bad. The idea was to get away from things that look like this:

… and move to something that looks more like ocean waves:

http://scrumreferencecard.com/scrum-reference-card/

It actually works. Faster! Better! More flexible! Less rework! Less waste! What’s not to like? The business will change its mind all the time (those crazy suits) and you’ll just do some Agile kungfu on it. Scrum CHOP!

The problem is that Agile (as commonly implemented) often feels like a whirlpool. Without tending to the human side — diversity, safety, and celebrating meaningful results — it becomes a treadmill. It’s a constant slog of monotonous rituals and meandering iterative development… like adding globs of wet sand to a sand sculpture at the beach. ‘Round and ‘round you go … introspecting in a hall of retrospective mirrors:

Retros. Planning. Backlog grooming. Acceptance criteria. Standup. Rinse repeat.

Without a focus on outcomes and results, you’re stuck on a feature factory treadmill. And you know what? Experienced people hate that. Crap made fast is still crap. They check out. Once you’ve graduated out of the pure bliss of releasing production-ready code, you start to wonder if anyone is using these “stories”. Is it working? Did you eventually build the car …

http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

… or are you stuck in a perpetual MVP exercise wondering when the “business” will figure things out?

Have you checked out the This American Life episode on the GM Nummi plant? If not, do so [here](http://www.thisamericanlife.org/radio- archives/episode/561/nummi-2015). What I found most interesting about this story is that GM couldn’t replicate the Nummi success in other plants. The original team — faced with an impending plant closure — visited Japan and had a transformative experience. They were empowered to save their plant and experienced amazing success. In other plants, that wasn’t the case. Those efforts failed.

Before, when GM ran this place, I dreaded coming to the plant. Management was always screaming and hollering. Now it is so different! I look forward to getting here and helping my team solve problems.

Humans enjoy the ebb and flow! They like ambitious visions and a challenge. We enjoy stories with a beginning, middle, and end. We like making a difference!

There is a certain zen to iterative development …

Esher Sisyphus or “Zen”?

And an almost “wax on / wax off” mystique …

Don’t forget to breath. Very important.

But Daniel eventually goes on to compete against the brutal Cobra Kai. There’s a story arc there.

All of that stuff you want: the scale, the growth , the speed, the quality, the control, the accountability, the predictability, the … agility is achievable without safety, diversity, and learning (at least for a short period of time). If you’re a big org and feel like some paint-by-numbers just implement SAFe.

To get to a higher level you’ll eventually need the empathy, inspiration, creativity, humanity, and novelty:

So, with that … think about ripples and impact. A powerful center, with power rippling outwards.

Appreciate your comments!

Maybe You’re Just Bored. And It’s Your Fault

It’s not the boss, the strategy, or the system. You’re just not in the right place and/or doing the right thing. And it’s your fault.

Maybe You’re Just Bored. And It’s Your Fault

It’s not the boss, the strategy, or the system. You’re just not in the

right place and/or doing the right thing. And it’s your fault.

I speak from experience.

Sound Familiar?

I’m 41. I like big challenges, missions, and asking why. I get bored easily when I can’t tackle those things.

I like rigor. I work hard and my work is considered valuable and high leverage. I don’t navigate internal politics well. I tease out of the root cause quickly. I want to fix those problems. I’ve been called the “canary in the coal-mine” multiple times. I’m impatient, stubborn, and lack tact. I relate to the front-line doers and like flat organizations. I believe most managers are just getting in the way.

That’s me, for better or worse.

It’s taken a while to **accept that many work situations left me bored and under-stimulated. That was a big step. Without that self-awareness I frequently sought stimulation by trying to fix the situation. **And we know how that goes … established systems are a beast, you get burnt out, leave, and it all starts over.

My Advice …

A friend in their mid-twenties sent me an email recently asking for advice. I saw a lot of me in him: hunger, sensitivity, drive, confidence mixed with insecurity, systems thinking, and the drive for a “better way”. I replied with this …

It’s your responsibility, and your responsibility alone, to seek out (or create) the environments where you can thrive. Your weaknesses shape your strengths. Without them you’d not be who you are. You could spend decades trying to be something you aren’t, or invest the time now being who you are.

My biggest “mistake” was not building a foundation earlier. Chipping away earlier. Accepting earlier. I was my own worst enemy for a long time.

Maybe you’re a better consultant! Maybe you should start a company! Maybe you need a better mission, or a better cause! Maybe you need to hang out with different people. Maybe people should pay you to be exactly who you are, warts and all? Do what it takes. You might even need to shut up and do the grunt work for a couple years (but keep the end-goal in mind).

Most importantly, start writing your own narrative. Because it will take a while. And wont be easy.

The next time you find yourself angst-ridden about your work … ask if you’re just under-stimulated. Are you bored? And why are you allowing that to be the case? How are you getting that fixed?

Do We Need Product Managers?

After reading the 745th blog post trying to define product management and product ownership ….

Do We Need Product Managers?

_After reading the 745th blog post trying to define product management

and product ownership …._

https://www.youtube.com/watch?v=uihgdgGBLKk

Yeah. I know. It depends. But …

To build a successful product you _do need _context, business savvy, domain knowledge, vision, customer empathy, technical prowess, communication skills, and [insert skill/hat here]. You need lots of hats:

But you don’t necessarily need Product Managers and/or Product Owners (people with those titles).

Businesses talk frequently about owning, single wringable necks and accountability. Someone needs to give the status update. Someone needs the visibility. Someone needs to be presentable enough to attend The Business (capitalized) meetings. The Business needs these things. Do they contribute to building a valuable product? That’s debateable. In addressing those needs, organizations often propagate anti-patterns that cause deep, lasting harm.

At conference after conference I hear about “bad product managers” and “incapable product owners”. I’ve heard product owner jokes in keynote talks. I’ve participated in multiple ad-hoc 5 Why exercises with strangers that identify product management as the root cause. Is it really that bad? I don’t think so. It’s safe to say that something else is going on. All of these well meaning people can’t suck so bad (although consultants would love for you to believe otherwise).

I think that the problem is 1) the pipe-dream, and 2) structuring the org around dysfunction. Time traveling to 2008, [here’s a description of the product owner role](https://www.mountaingoatsoftware.com/agile/scrum/product- owner):

Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting any agile software development project.

The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed.

Wow. That sounds awesome. This superhero will figure it all out for us, and we’ll be off to the races. We’ll have someone to blame if there is no vision. They’ll know what to build, and we’ll build it. So we dutifully assign these people to 6–12 engineers, regardless of whether those 6–12 engineers build a singular product, and hope for the best.

A CTO (who prides himself on being “Agile”) recently told me:

Well John, you know that all engineers secretly want to be told what to build. We like to build. We don’t want to waste our time in meetings

In addition to this being patently false — many engineers I know very much care about impact — we know this approach fails. We know we’re wrong often. At a minimum we know we’re rarely 100% right when we first ship something. And time is a cruel mistress. But the pipe-dream exists.

The reality is that most product managers are overworked, spread too thin, and under-empowered. They’re the go-between. What people recognize as “bad product management” can almost always be traced back to deeper organizational challenges. These challenges manifest in the connective tissue of the organization (the product team). Product makes for a convenient scapegoat.

Every PM can relate to that awkward moment when someone with “C” in their name is helicopter managing the product, while at the same time the team is beating them up for changing priorities. That’s not a recipe for attracting and retaining the best.

I often hear about the benefits of “creative tension” between the Product, Engineering, and Sales organizations. To which I respond with something like:

Why do you insist on silo-ing the product and engineering teams? Is engineering just a factory in your mind? How do you actually benefit from this tension? More importantly, what do your customers think about all of these coordination meetings? Why not a single product development organization?

Some organizations have taken the bold step of a single product development organization, but this is pretty rare. Toyota had the famed chief engineer role, a staple of the value-stream oriented lean product development model. But the reality remains: most organizations are structured around their needs (and dysfunctions), and not the needs of the customer. They create product roles because “that’s what people do” instead of asking “what must we do for our customers”. The org becomes fatter, taller, less skilled, less resilient, less adaptable, and more complex to navigate.

You start optimizing around your company structure, and not what people actually need.

Probing Questions

Start by asking yourself some questions …

Do your PMs own outcomes or the delivery of features? If the delivery of features, why not just hire skilled project managers?
By hiring the single PM, are you failing to provide other much needed pieces of context to your teams? Are your PMs skilled at ________ ?
Why does every group of 6 or 12 engineers and UX need a product owner? Is that team exclusively responsible for an actual product? If they controlled the budget would they actually hire the PO full-time? Or would they put a rec out for other, more specific needs (e.g. “attend meeting X and let us know if there are changes”)
What do your teams need? What do your customers need? What % of your PM’s day is actually benefitting the customer vs. the internal needs of your organization? Why?
How do your product managers insulate your engineering teams? How could you eliminate the need to “protect the teams from __________” ?
Could you afford fewer, but more highly skilled product managers and product owners? Even if they had larger teams?
Are there more effective ways to deliver status checks?
Why do you need separate Product org and Engineering orgs? How does the customer benefit?
Could you rotate the PO role? Are there other folks in the organization who can supply the context, thereby cutting out the noise / signal loss? Do your needs remain constant? If not, can your PMs/POs remain that adaptable? Or do you expect them to just bail?
Are your most skilled product managers/owners working on the front lines?
Are your expectations for your product team reasonable? Is there enough time in the day to actually do the work adequately?
Can you bring the silos of your organization closer together? Such that the overhead of coordination would drop and benefit your customers? And what would that do to your product team?

So yeah. Sometimes you’ll end up with the someone with the Product Manager or Product Owner title. But sometimes you wont. Before you write that job ad, consider what you need and/or what you need to do to make that person successful.

Explaining Product/Market Fit in 60 Seconds

Your product shows potential. But does it perform?

Explaining Product/Market Fit in 60 Seconds

Your product shows potential. But does it perform?

Product/market fit is a slippery term. I think of it as follows (3Ps):

Pain

You’ve validated a pain exists and an identifiable group of people are willing to fork over cash to see that problem fixed

Potential

Your product shows **potential. **That group of people want to give your product a shot. They’re willing to engage with your product/organization in the hopes that it will solve their pain.

Performance

Your product performs. It actually solves / alleviates the pain. It produces valuable outcomes and continues to produce valuable outcomes month after month, year after year. You continue to innovate on your solution to the problem/pain, and realize the potential.

This is why Product/market fit is fluid and hard to pin down, especially when you’re tackling ubiquitous problems.

**Pain **is relatively easy. Most pains are known (though some discover pains we didn’t even know we had).
With some work, teams can develop products that show potential. It’s harder, but doable. The deeper the pain, the more people are willing to take chances on things with potential. Especially in tech, a lot of companies are throwing around money just to try things out.
Performance is where things get tough. The rubber hits the road.

The danger is mistaking pain and potential for performance. Pain and potential can get you reasonably far, certainly past a couple rounds of funding. But it all eventually boils down to performance. Large swaths of startup technology hasn’t advanced beyond the potential phase. Which is OK — there might be a huge upside — but it is what it is.

The lesson: differentiate product potential from product performance when talking about Product Market Fit.

16 Quick Product Management Tips

Some quick coffee fueled snippets from a product coaching email exchange …

16 Quick Product Management Tips

PM work isn’t easy ….

Some quick coffee fueled snippets from a product coaching email exchange …

Consider the following …

Approach all PM advice with some skepticism. What is the context? What is the product? What is the product stage? Who is the customer?
Senior engineers care deeply about the impact of their work, and check out when they don’t sense that impact. Being a cog in a feature-factory is no fun. Address that or risk losing your best
Batch your planning and approach it “just in time”. The floors of companies are littered with planning in progress. You can plan 6 months of work in 60 minutes, so why do it ahead of time?
Be proactive about giving the team slack to work down debt. Let them know you’re open to that discussion
There’s a spectrum of actionable context. More experience = greater ability to act on (and reject) data, context, and details. Junior folks wont have that skill (yet). Point is … respect the need for more context as it gives your best team members the information they need to solve the problem. For junior team members respect that they’re constantly upping their game. Explain how you’re connecting the dots …
Leave time to iterate. This is frequently given lip service. “Well, we’ll watch for things and then — while you’re building this new widget — we’ll work it in.” This never (or rarely) happens … and 2 years later, when the context is lost, doesn’t count
Cultivate a meaningful ebb and flow. Iterative development can suck the life out of a team. People like challenges and missions
Respect the dynamic. Writing production-quality code and designing production-quality user experiences is extremely demanding. There are “passing tests” (usability tests included). As a PM, do you have passing tests?
Become a master of driving a shared understanding. But realize that meetings are one of many ways to achieve that (and often the least effective). Visualize things. Record things. Repeat things, in person
Creative work requires downtime. What defines productivity in your world (keyboard tapping) doesn’t equal productivity in the UX and Engineering world
If the “best ideas win” then make sure that everyone has a fair shot at offering ideas. The reality is that your ideas aren’t always the best ideas. More importantly, cultivate a deep understanding of the problem, or commit to learn more about the problem. The good ideas will flow
Quantify the status quo. Too many teams dream up success metrics with no baseline. What is the customer’s current behavior? Later, check to see if your work impacted this behavior
“Leftover” work and design/research don’t work well with each other. It’s two different mindsets. Don’t do six 1hr research activities spread over a week while you tie up loose ends. Finish A, and then start B with two days of focused work. That “staggered sprint” thing or “getting ahead of the sprint” … just not a fan. All efficiencies disappear despite it making sense on paper
It’s tempting to force convergence (“we need the mockups now!”). The best ideas emerge after an almost uncomfortable level of divergence. Protect this, even if it feels messy
You have to be willing to throw code away and start over. As a PM its easy to rationalize otherwise.
It’s important to differentiate between linear and non-linear impacts in product development. You can’t scale certain things 2x and expect other things to scale 2x (e.g. # of personas and size of team required to serve those personas)

OK. Back to coffee and [some doodling](https://medium.com/personal- growth/10-things-i-learned-by-doodling-for-100-days-straight- a802753c5a25#.2x70dd2ny).

Why Startups Need 3rd Party Accountability Coaches

As a startup founder you’ll get a lot of advice and feedback. Everyone has opinions. Everyone wants you to avoid pitfall X,Y, and Z. Your…

Why Startups Need 3rd Party Accountability Coaches

As a startup founder you’ll get a lot of advice and feedback. Everyone has opinions. Everyone wants you to avoid pitfall X,Y, and Z. Your board, your employees, your fellow founders, and your customers will all have something to say. The advice is often conflicting and deafening.

More advice doesn’t equal more clarity and at its worst (e.g. board advice) it forces violent swings in strategy and tactics. What’s needed is unbiased accountability. Is it working? Where’s the data? How are your experiments going? Are you staying true to your values? Instead, you get shotgun blasts of well-meaning but invariably biased advice.

The problem is compounded because founders exist in a cognitive bias petri dish. It’s the achilles heel of the lean startup approach. A disciplined, experimental approach sounds good in theory. But that all falls apart when someone dangles money in your face, an investor mentions an off-handed challenge, the big partner calls, or someone fluffs your ego.

So the advice is biased and you are biased … the well-meaning leading the blind.

The irony is that most founders, at some point, were the one’s giving the good advice and feedback. The rolls were reversed. And someone wasn’t listening. That frustration, and the conviction to “not make these silly mistakes”, is at the root of many startup inception stories. But like parents promising to never repeat the sins of their parents, it’s much harder to pull off in practice.

What you need, is someone with no skin in the game to hold you accountable. Not an employee, not another founder, not someone on your board, and not a friend in the business. Find that person. Write things down. Meet regularly. Describe your strategy, pivot/proceed points, and milestones. Be disciplined and focused. And get dispassionate advice linked to YOUR goals.

The CynAgileanUXanbanicrumify Method

3.0, ™, Copyright 1885–2016

The CynAgileanUXanbanicrumify Method

3.0, ™, Copyright 1885–2016

In this past month, I have used the following practices, methodologies, perspectives, etc. I’ve flattened the list (many are related and nest logically):

Agile, Modern Agile, Lean, [Lean Product Development](http://www.npd- solutions.com/lpdpractices.html), [Lean ](http://www.jeffgothelf.com/lean-ux- book/)UX, Agile UX, Design Thinking, Jobs-To-Be- Done, Scrum, Lean Analytics, Kanban, Kanban Method, Enterprise Service Planning, Google Ventures Sprint Process, [The Spotify Model](https://labs.spotify.com/2014/03/27/spotify-engineering-culture- part-1/) (and Henrik Kniberg ‘s work more generally), Organize for Complexity, Impact Mapping, Cynefin, Management 3.0, Lean Startup, [Customer Development](https://steveblank.com/2012/03/29/nail-the-customer-development- manifesto/), [Radical Focus (OKRs)](http://eleganthack.com/radical-focus-is- here/), Don Reinertsen’s The Principles of Product Development: Flow, Systems Thinking

I am eternally grateful for the great work these communities and individuals have done. My personal ROI to learn, mix, match, and apply these methods has been amazing. Sure it looks like a buzzword soup. But that’s what learning is all about. “Consume responsibly! Test for staining!”

If you think its easy to do research, write a book, organize conferences, give talks, complete projects, and [ — — — — ] you are mistaken. Sure, much of it isn’t “new” (and the curators wouldn’t claim otherwise) but the presentation is crisp and thoughtful. In some cases — take Lean and Agile, for example — the body of work is massive, spanning decades and tens of thousands of people. Sure, some people want to cash in. But don’t we all, on some level?

Put bluntly, there are no shortage of ideas and perspectives to apply to your current challenge. Perhaps too many. It is a “learner’s market” … you’ve got a lot to work with. However ….

In most cases, organizations are not blocked because they picked the “wrong model”. Rather, they are blocked because their organization lacks the pre- requisites for experimentation, reflection, and continuous improvement (a challenge addressed in many of these approaches, though often glossed over by the reader). Or they’re truly burdened by past decisions. There’s nothing original in this observation. We’ve all played the old salt reminding people that there is no magic bullet. [There’s a reason why it took years for Inuit to adopt a design thinking approach](https://hbr.org/2015/01/intuits-ceo-on- building-a-design-driven-company).

That said, I find myself making the same mistakes repeatedly:

Taking too broad of a systems thinking approach. Sometimes the problem is truly local. You’ve got a toxic, power hungry, maniacal person in a position of power. And that sucks. Granted, the fact that they remain in power is the root cause, but I digress :)
You can’t measure someone’s passion for change by how loud/quite they are. Some people love to complain. Others are scared to speak out. Partner and form alliances with care
Timing. Many orgs are digging out from a mountain of ____ debt. It manifests as having product issues, but the reality is that nothing tangibly will happen in that area until they’ve worked out other issues
Assuming that folks feel safe to experiment and fail. An executive sponsor may be terrified at the prospect of trying X and failing on the first go round
Payday. Some people are just riding things out. They’re waiting to be 100% vested. They have a lot to win and gain. It doesn’t mean they approve of what’s going on, but just that they’ve come to peace with their desired outcome
The power of “good enough”. Because something is working moderately well doesn’t mean that 1) it will continue to work, 2) it can be improved upon without major changes. But that is difficult to explain and sometimes very difficult to refute
Only the “front-line” is bought in. Most of these approaches appeal to the front lines. But that doesn’t mean anyone else is paying attention. The reverse is often the case
Underestimating the sheer power of the status quo. It is easy to imagine it as static, instead of respecting the powerful dynamics required to keep something “stable”

Not being empathetic to “change PTSD” … namely, the prior damage of poorly thought out change initiatives done under the banner of a “way”. Lots of senior execs suffer from this, and it drives their skepticism
The need for people to own and take credit for improvements and change. In many cases the methodology is being “hired” to give a particular team member power and influence. And sometimes we fall into that trap ourselves. I’ve dealt with people who steadfastly resisted methodology X, and then embraced X+”UX” because they owned UX
Lack of shared understanding. My “customer focused” is your “UX obsessed” is their “build features to close the deal”
Limited CIP: change in progress. The limited capacity of any system to absorb change. It wont all happen at once
Believing everyone thinks and learns the same way
Not reflecting and retro-ing on the change effort itself. Is it working? Why? Why not?

So, when mixing and matching your favorite perspectives (or implementing your own), remember to keep this all in mind. Work first on the operating system: cultivating an environment friendly to experimentation, reflection, and continuous improvement. And then go to town at a sustainable pace.

It’s All Good. Until You’re Screwed

There’s no free lunch or magic strategy.

It’s All Good. Until You’re Screwed

There’s no free lunch or magic strategy.

Costs and risk are frequently invisible. Effects are non-linear and difficult to predict. What makes sense now often makes no sense in the long term. We all struggle with our biases. The sensible response proves to be irrational.

It is never easy …

We destroy our goals for three quarters, but end up struggling to pick up the pieces for the next two quarters
We pursue growth, but end up underestimating the accumulation of technical and cultural debt
We prevent errors, but end up overly confident that errors will be caught
We celebrate healthy tension, but end up with the mediocre, but less objectionable option
We try to keep everyone in the loop, but end up drowning in meetings and communications
We carefully define roles and responsibilities, but end up with too many constraints and too heavily matrixed team members
We design the perfect interface, but end up incapable of extending it for a new use-case
We hire 10x doers, but end up in need of 10x coaches and mentors
We seek alignment, but end up with too much momentum and process to pivot
We promote autonomy, but end up incapable of mustering the troops to defend against an immediate threat
We promote harmony, but end up having trouble with uncomfortable conversations
We stress individual accountability, but end up squashing team ownership
We chase velocity, but end up quickly shipping mediocre outcomes
We bail out a team, but end up limiting their ability to self-rescue in the future
We target more personas with our product, but end up with feature soup
We defeat one competitor, but end up leaving ourselves vulnerable to disruption

And that’s life. What counts is our ability to observe and respond … to question the rational path, experiment, reflect, and repeat. What works now, might not work tomorrow! Ask yourself: what is restricting our ability to change course when the course is no longer smart?

Use a light touch and resist the urge to control and predict.

Cheers!

John

PMs/POs: 25 Things You Can Try Now

What can you do in the next week or two to be a better product manager?

PMs/POs: 25 Things You Can Try Now

What can you do in the next week or two to be a better product manager?

I write these listicles for friends and consulting clients and share them when I can:

Call five customers and ask them the same, non-leading questions. Share an overview with your team. Better yet, invite folks to listen in
Observe five people using your product to get their daily work done. GoToMeeting is fine for this. Ask to be a fly on the wall. Edit a set of interesting clips. Share with your team
Conduct a story-mapping exercise (see Jeff Patton’s book for help)
Collaborate with your UX team to conduct a usability test _right now _for an upcoming feature (a paper prototype is fine). Do a couple tests, iterate, and repeat
Watch this video from Sian Townsend on jobs-to-be-done. Consider how you could use jobs-to-be-done to replace personas, roadmap items, user stories, etc.
Make sure you understand exactly how your business makes money (or intends to make money). What assumptions has your company made about the fundamentals? What must remain true for you to continue with business as usual? Sketch it out, and explain it to someone who has just started at your company. If you service a specific vertical, learn exactly how your customers make money as well
Take a field trip with your team (yes, a real trip, with a van, with engineers and UX) to visit a customer. Spend a couple minutes on the drive back to capture key learnings
Set a couple dozen Google Alerts for news on competitors, customers, and specific domains/markets
Break down silos. Do you speak to someone without your team present? Figure out how to have a conversation together so you aren’t the blocker and/or go-between
Invite customers to the office and schedule a series of activities that they can participate in (e.g. sketching, customer journey mapping, etc.)
Go on site with a customer and record a no-holes-barred, “this is how you could completely change how I work”, video. Bring the inspiration back to the team
Figure out how to have an honest and safe discussion with your team about what is working, and what isn’t working. All too often the presence of the PO/PM stifles conversation (you’d be amazed what they say when you aren’t around). Change that dynamic!
Create a “that drives me crazy” list — things that drive your internal team crazy when they use the product — and dedicate a couple days to knock those things out. It isn’t guaranteed to be customer facing, but it sure will boost morale
Institute a just-in-time meeting policy. Make a Kanban board public. Keep adding agenda items to the board until there is enough stuff to fill a 45 minute meeting. Have the meeting. There’s no sense in talking about stuff until it is actionable and pertinent
Get some photos of real customers who will benefit from your immediate work, and put them up on the wall. Call them as well. Personas are great and all, but real people and real stories inspire people
Organize a customer panel to discuss topics pertaining to an upcoming initiative. Invite the whole team. Seeing the differences and similarities across customers can be eye opening. Plus it’s fun
Partner with your onboarding / customer success / account management team and schedule regular interviews and usability tests with new customers. Fresh eyes are super valuable
Remove a rarely used feature and figure out how to message this to your customers. That wasn’t that bad, was it!?
Work to break through any of the stereotypes you hold about your team (e.g. engineers don’t care about UX, and UX doesn’t care about the business). Invite someone to lunch. Ask about what drives the people you work with
Before you use the words complicated and complex, consider this model from David Snowden . Ask whether the problem you are solving is complicated or complex
Conduct a targeted survey in-app. The targeting matters… you want highly qualified responses. The silent majority of users has a lot to say
Check the adoption of your past five ship and reflect on your product decisions together
Make a commitment to report back to your organization on the outcomes generated from your current effort. Consider a pre-cap design studio to flesh out what you want to communicate
Schedule a session where everyone — yes everyone, including engineers — draws ideas, prototypes, etc. Make it official by calling it a design sprint
Do some research on Service Design . Consider how your product is an integral part of a higher level service, and reach out to other parts of the organization to understand how you can help deliver that service more effectively. Customer journey mapping is a great place to start

The Healthy Tension Trap

Seriously! We’re all Product Developers!

The Healthy Tension Trap

Seriously! We’re all Product Developers!

I’m sure you’ve heard something like this before…

A good designer wants an elegant, polished solution. A good PM wants to solve the right problem and optimise for speed. A good engineer wants an implementation that’s maintainable and efficient. (source)

And then you’ll hear about healthy tension. The idea is that everyone will “advocate” for their respective interests, and out will pop an awesome product. The thinking is that without the keen eye of UX, the interface will end up looking like a command prompt. Or that without Product cracking the whip, Engineering will re-factor their code a dozen times, and UX will polish every pixel (repeatedly, those wacky designers).

Do you know what happens instead (in many cases)? Mediocrity and complacency. Green + Red != Christmas. No…. Green + Red = Brown (an “[icky mix that doesn’t bode well for your pigment/paint](https://www.quora.com/What-color-does-green- and-red-make)”).

Instead of advocating (and healthfully debating) for the **_best idea, or the right way to deliver value to customers, _**you end up with bunch of people playing into various stereotypes, or worse yet chasing the incentives / rewards of their functional group over a focus on customer needs.

A healthy team will debate, argue, test, and tweak. It’ll get downright heated sometimes. _Healthy tension _assumes no one can think beyond their functional silo, look at the data, or leverage the respective backgrounds and skills of their teammates in a productive, non-tense way. Someone wins, and someone loses.

Quotes [like this](http://www.zdnet.com/article/engineering-design-need-to-go- hand-in-hand-for-enterprise-software-execs/) drive me crazy:

“There’s some healthy tension there,” McCoy remarked. “At the end of the day, the product manager has a primary responsibility to the business. The designer has a primary responsibility to the user.”

The dreaded Business raises its ugly head again (as if there is this clean line between the engineering org — the factory — and the business/product folks who know what to build). Designers! Have you been in this position and rocked that healthy tension? Was it fun representing that user? Did you “win” ?

We are all product developers! We make stuff people use. We wear a ton of hats. We care! I’m not saying you don’t have a speciality, and a community of practitioners to learn from, but that is different from carving up your product development organization.

No one has ever given me a persuasive reason why you can’t just bag the three functional groups and have a single product development team.

But, but, but …. the CTO doesn’t care about UX! Bad reason. But, but, but … we need a Product org to hold the Engineering org accountable. Bad reason. Most of the reasons have to do with internal personalities, trust, chains of command, and outdated ideas about how healthy tension can benefit the product development process. They’re rooted in the idea that you need this layer (product management) to sit between the business and the engineering factory, and that UX will sort of float there advocating for good design when no one will listen. And that we’re all myopically selfish.

Replace tension with trust and diversity. It achieves the same outcome without the death-by-matrix baggage.

As mentioned in previous posts, the customer doesn’t care one bit how you structure your org. But if they witnessed the typical positioning, politicking, and “advocating” that happens in most organizations, they’d probably laugh. Solve my problem, so I can give you money! And leverage everyone’s skills to make that happen, regardless of context, functional group, or agenda.

Product Development Nerds Unite

I want to go to a conference with engineers, UX, customer success ninjas, data scientists, and product managers/owners! And talk about…

Product Development Nerds Unite

I want to go to a conference with engineers, UX, customer success ninjas,

data scientists, and product managers/owners! And talk about building stuff humans value.

Random stock photo from [here](http://www.onlineschoolscenter.com/30-high- paying-trade-school-degrees/) . Sadly, without this image, I’ll have about 1/5th the number of readers.

There are product management conferences, UX conferences, software engineering conferences, customer success conferences, Agile conferences, and [design thinking bootcamps](http://www.gsb.stanford.edu/exec-ed/programs/design-thinking-boot- camp) ($12,500 for four days). And then there are those pesky tracks (bless the single track conferences, by the way, because I’m a track swinger).

Help me out here. I must be missing the obvious.

Barring some attempts (e.g. LeanWX 2016 by the LeanUX crew) and the startup focused conferences [Lean Startup](http://leanstartup.co/2016-conference/?gclid =CjwKEAjw34i_BRDH9fbylbDJw1gSJAAvIFqUwtVJHkqNskV- CCBBNGgdg_f7JK2WrWfHX20Q_V7maRoCzSDw_wcB), I can’t seem to find a decent product development conference. You know, somewhere where the people who do the work — the people who wear the various hats — get together and talk about how to make the magic happen. We have all sorts of opportunities to learn how to make OUR magic happen, but not THE MAGIC.

Weary consultants have rightfully embraced organizational design as their last stand. It’s HOT. It’s where the money is, and frankly it is where the problem is as well. Either that, or the big bugaboo scaling. Whole-org Agility. Lean Startup for the Enterprise. Complexity Theory. The Learning Organization. Teal Orgs (what a color pick). Still…where do those of us in the trenches take off our respective hats and nerd out about the craft of product development? I get it, the whole-org stuff cuts big checks, but …

Remember when UX [had to figure out how to coexist with Agile](http://www.uxmatters.com/mt/archives/2011/04/integrating-ux-into-agile- development.php)? And when UX [decided to coexist with Lean?](https://www.uxpin.com/studio/blog/lean-ux-vs-agile-ux-is- there-a-difference/) Or when Product Managers needed to be [trained on devops](http://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and- devops-a-cheatsheet-for-the-rest-of-us/)? Or folks [finally shed some light on the Agile PO Role](http://www.romanpichler.com/blog/the-product-owner- responsibilities/) (thanks Roman Pichler)? Or when people finally realized they were guessing all the time and [needed to validate outcomes](https://www.thoughtworks.com/insights/blog/how-implement-hypothesis- driven-development)? There’s still work to be done, but I’ll pull out this quote from The Lean Mindset by Mary Poppendieck and Tom Poppendieck (with illustrations from Henrik Kniberg):

We have written three books about software development, but we couldn’t write a fourth, because the islands of software development have largely disappeared. In their place we find a new landscape, one in which infrastructure is a commodity and multidisciplinary teams are expected to ask the right questions, solve the right problems, and deliver solutions that customers love. True, those solutions are often software-intensive. In fact, just about everything is software-intensive these days, so isolating software on its own island doesn’t make much sense anymore.

To what degree are we reinforcing these islands with the conferences we organize, departments we create, blog posts we write, and titles we assign? I’m not belittling the importance of craft, disciplines, and areas of practice. It’s all important and we’re getting pretty damn good at it. But I’m asking whether you also need an equal focus — a truly cross-functional focus — on the collaborative craft.

Are we structuring our learning like we have structured our orgs? Are we worrying more about the bastions of product, ux, agile coaching, and engineering more than the success of what we build?

This is why I love Jeff Patton’s story mapping book (see this video for a summary). On the surface the book is about story mapping, but the subtitle “Discover the Whole Story, Build the Right Product” is pretty spot on. It is a full-contact, full-team sport. And everyone plays.

Where do I go to get this fix? I love me some UX and Product conferences. But I’m also tired of people talking about other people when they’re not in the room. Where can we all get in the same room?

Let’s discuss in the comments (if you feel like it)

The Overlap

The Messy World of Modern Software Product Development (With User Interfaces)

The Overlap

The Messy World of Modern Software Product Development (With User

Interfaces)

In forward thinking product development organizations, product management and UX have become increasingly overlapped. Concurrently, we have seen a move towards collaborative design — involving engineers and other stakeholders in the design process. These two factors have had a dramatic impact on how product development teams organize, work, and deliver value to customers. In this post I am going to explore some of these impacts.

A Vignette From the Trenches

Everyone is reasonably good at everything (except maybe Engineering, though some UX and Product folks have chops), and really good at some things…

First, let me paint a picture based on my career and recent personal experience. Imagine a team with a UX researcher, UX designer, product owner, engineers, quality assurance, customer success rep, and an agile coach.

They’re all in a van visiting a customer’s office. They’ve been spending the last couple days engaged in various activities: design studios, customer journey mapping, user story mapping, listening to customer interviews, and building a backlog of experiments to run.

The walls back at their office are plastered with artifacts…stickies from a pre-mortem, a story map, wireframes (drawn by everyone), and a lean canvas. Everyone is engaged and contributing.

The PO isn’t the single owner of the backlog (the whole team owns it). The UX designer isn’t the single owner of the design (the whole team owns it, and is reasonably design savvy as a whole). The PO isn’t the sole owner of defining the problem (the whole team explored it, with help from the UX researcher who did a deep dive a week prior).

And the pairing! QA is pairing with UX to explore interesting edge-cases. An engineer paired with the customer success rep to analyze existing customer data. And the UX researcher paired with the product owner and another engineer prior to the effort to do some preliminary research.

That Sounds Batshit Crazy

This only happens in the movies… As a designer this would drive me crazy …Can’t they just write a spec?

Sound terribly inefficient? Perhaps, though we are chasing efficacy and outcomes and the madness addresses these goals remarkably well
Sound impossible without a ton of resources? Probably, if you only just hired your first UX designer
**Sound completely foreign, and you have a tough time believing things actually function this way? **It’s rare, but this is how some of the best cross-functional product development teams operate now (2016)

PUX

The product owner gets their world rocked…

The role that has been most impacted by these shifts is the product owner role. No exaggeration, but my role recently as a UX researcher (at a West Coast, recently IPOed SaaS company) was nearly indistinguishable from what I _used _to do as a PM/PO a decade ago:

User stories? Yup, as an output of facilitated activities with the team.
Deep customer/user research? Yup, prior to and during the initiative.
Measuring the impact of the initiative? Yup, both qualitatively and quantitatively. Lines are blurred.

A Director of Product Management remarks:

My biggest problem is the overlaps. Our UX folks and product owners have such an overlap of responsibilities and skills, that it is difficult to keep everyone engaged. I almost feel like a new role or title is in order. Sure, the PO does some of the tactical record-keeping stuff. They do the status checks and keep me informed. But the reality is that this team could run well without one (a PO).

My challenge is that we have already established these structures. I can’t just say “don’t work”. I have people to engage. I want them to share in the excitement. But in some cases their getting overwhelmed by all of these very experienced people

This isn’t an environment that an associate product manager will navigate with grace. It’s hard. It has become a game of who can contribute valuable context and skills to the soup. A pure meritocracy. The customer needs no representation because the customer is literally on the phone and the team is decently skilled at asking the right questions. Heavy prioritization is unnecessary because the team is moving quickly enough to try new things (with real customers) at will.

One major factor here is the rise of UX. The UX tool chest has always been broad (research, validation, iteration, etc.). They just didn’t get a chance to flex their muscles until recently. Turns out designers make great sensemakers and untanglers and know a thing or two about customer value. Throw in collaborative design, and suddenly your engineers are a bunch of entry level UXers and product owners. Cool huh?

Which in turn impacts the product owner. The formulaic “1 PO per one or two teams” starts to feel very archaic. In its place we ask “what do we need, and who can provide what we need?”:

If in-depth data science is required, we should find a data scientist
If coordination with the marketing team is required, we should find a coordinator
If more context is needed about the business objective, we should find a business analyst

You get the idea. To be valuable, product owners must leverage differentiated skills. My prediction: the product owner/product manager titles will morph as new, more specialized roles march to the trenches. [I have a simple table describing how I see the product manager role evolving](https://medium.com/@johnpcutler/the-evolving-product-manager-role- 6f288bbc3cda).

The Clan

Where do I belong? Who cuts my check?

In a lightly matrixed environment, it is clear who your clan is. You have a boss. You go back to home base to recharge. Your services are “loaned out” (or even billed out, in some cases) to these teams. It’s a services model. Engineers form the nucleus, and you swoop in when you can to help out.

Things are different with these highly formed, normed, stormed, and performing teams. You now have a team (a squad?). You’ve gone through rough times and happy times. They’ve called you out in a retrospective for slacking. You made up, and formed a stronger bond after the rift.

The matrix is hard. It is made _much harder _when you are fully embedded on a team. It’s almost not a matrix anymore, except for the pesky question of who gives you your marching orders to a new project, a raise, promotes you, and coaches you. Is it the people who have contact with you day to day? Or the whole network of coordinators and managers who exist to keep the whole matrix pumping?

The services model brand of matrixing has given way to being fully embedded. Everyone is invited to the retrospective. Which ironically has made things much more confusing. My prediction is that we’ll see the matrix dissolve with [Spotify-like chapters](http://www.full-stackagile.com/2016/02/14/team- organisation-squads-chapters-tribes-and-guilds/) providing the functional camaraderie, hiring, and career development. Product and UX teams must adopt new structures to evolve.

Patterns and Consistency

It won’t happen without a pattern library…

Jeff Gothelf makes a great case for pattern libraries in [his LeanUX book](https://www.amazon.com/dp/B0074KA0A4/ref=dp-kindle- redirect?_encoding=UTF8&btkr=1). Reflecting on the last couple years I can say, without a doubt, that pattern libraries are one of the core components in this new reality. To achieve any level of consistency in the midst of all this independence and autonomy, you’ll need more than weekly design reviews. Things are moving too fast for consistency to take work. Consistency needs to be automatic. A solid _live _pattern library also empowers rapid prototyping and collaborative design. If using the _right _pattern takes any extra work, then the wrong pattern will hit production.

Simply put, getting the plumbing straight for this needs to happen. It needs to be made a priority. But pulling it together will pay massive dividends.

T-Shaped On Purpose (Or By Accident)

A little of this, a little o’that, and a lot of that…

Whether we like it or not, in this model we’re all becoming more T-Shaped. Wikipedia has some good “Also Known As” terms for T-Shaped:

Versatilist
Generalizing Specialist
Technical Craftsperson
Renaissance Developer
Master Generalist

The net effect? Well, everyone has something to say about UX and product decisions. It might not be perfectly informed, but it’s not like you’re operating in a vacuum. Low and behold:

The engineer has a better UX solution
The team refuses to release the crappy MVP
The product owner can wireframe like a bat-out-of-hell
We all have trained for years to do things that aren’t as easy as they seem (but the team will think they’re trivial)

This requires a big dose of humility, perspective, and empathy. Great story. After finishing and summarizing a customer call (audio edit and notes), I asked an engineer for some technical help. He solved it with a brilliant one- liner.

Me: Dude, that was amazing! I could never do that in a million years.
Eng: No, no … I could teach you. That call was amazing. Great stuff. I’d never be able to do that in a million years.
Me: No, no … I could teach you.

Get used to not being the smartest person in the room. And get used to having to show people your value, instead of hiding behind process or titles. In prior realities someone would toss an idea over the wall, and another team would pick it up. They’d grumble and curse about your mistakes and incompetence, but it would never get real. Now things get real, and that’s OK because you’ve made your environment safe right?

If not, you’re in trouble. Scuttlebutt makes this all fall apart.

Speaking Engineer, UX, Product, QA

We’re all on A spectrum…

What used to get resolved with silos, departments, process, and gatekeepers, is now solved by people working it out together. Newsflash: engineers, UX, QA, and [insert functional area here] don’t always communicate the same way. For teams to function like this you need help (Agile Coaching?), time, and patience. You can’t just drop a junior person into the mix and hope they “pick it up”. To an outsider it’ll seem crazy.

We all have to develop great communication skills. There is no filter, and waiting around for one would be kind of silly.

In Closing

This has been rambling, and I’ll probably go deeper in future posts. Let me try to recap:

A lot of rules, process, and titles get messed up the further you advance down the road towards fully autonomous, cross-functional teams. If you try to cling to the old way, you’ll really confuse people. You have to take the plunge to discover new structures and ways of working (which will also confuse people)
The further you evolve the more challenging the PO role becomes
The Matrix dissolves or morphs. New structures and ways of working rise from the ashes. Anyone can provide value anywhere. You’ll still need to become an expert at melding with new teams though
Anything that happens “just because” doesn’t cut it. Is the team functioning with the necessary skills and hats? If not, change things
We need to adapt to a new reality of T-Shaped individuals, and learn how to communicate without pre-defined processes
It’s messy as hell! And the tendency is to say “oh, it’s too messy and inefficient”. But if you let these types of teams build their mojo you’ll be blown away by the results

6 Questions to Guide Continuous Improvement

Do the work…

6 Questions to Guide Continuous Improvement

Do the work…

There’s no silver bullet: continuous improvement takes resources and work, humility, empathy, and [teaming](http://www.wiley.com/WileyCDA/WileyTitle /productCd-078797093X.html). It is less about the methodology you pick (across hundreds of templates and books you’ll find remarkably similar themes these days) and more about the work you do, and the degree to which you can reflect on the meta-process of improving how you improve.

Which means we need to heed [Steven Pressfield’s advice and Do The Work](https://www.amazon.com/dp/B00NK0MJBK/ref=dp-kindle- redirect?_encoding=UTF8&btkr=1).

Give it a try!

Below you’ll find 6 questions that I have found particularly useful for guiding continuous improvement efforts. Gather a cross-section from your team — mixed seniority and functional areas — and have a conversation about these questions. Of course, you’ll need safety (see question 1) to have the conversation (see question 6), but maybe that is your starting point. That’s your first hurdle. You have to start somewhere.

See the Notes section for some commentary on these questions

How effective are we at:

Maintaining a safe and healthy environment for individuals and teams?
Resolving areas of widespread cognitive dissonance?
Learning and converting our learnings into customer value?
Dampening the negative impacts of scaling and growth?
Helping our people and teams grow?
Sensing changes to, and continuously improving on the the areas above?

Talk about it. What have you observed? What is the delta since you last spoke? How do your individual biases impact your perception of what you have observed? Are you hearing all voices? Are you missing data? Where are the opportunities for improvement? What would happen if you did nothing? Might certain things just work themselves out?

One of my mentors wisely cautioned:

Fight the temptation to see continuous improvement as a conduit for your pet projects and career advancement. It’s tempting. One of the biggest blockers to change is the desire to take credit for it.

Set a “Change In Progress” limit and prioritize safe-to-fail experiments. Too much change or change that is too prescriptive is the enemy of successful evolution. Stop starting and start finishing. Consider a continuous improvement Kanban board detailing ongoing efforts. Rinse and repeat. [As David Snowden writes:](https://hbr.org/2007/11/a-leaders-framework-for- decision-making)

Instructive patterns can emerge if the leader conducts experiments that are safe to fail. That is why, instead of attempting to impose a course of action, leaders must patiently allow the path forward to reveal itself. They need to probe first, then sense, and then respond.

This requires a certain level of introspection and humility. What if a leader is contributing to the problem? At the root of cognitive dissonance (2) we often find friction between leaders which manifests in unclear objectives and unnecessary tension. To see our own failings more clearly it may be necessary to cast a wider net for data (e.g. engagement surveys, 360 and peer reviews, etc.) Leaders are, in that regard, team members. It is Team with a capital “T”.

Notes

Safe environments welcome diversity, risk taking, experimentation, dissent, and sharing difficult feedback. Individuals can be authentic. Unsafe environments do this selectively, or not at all
Examples might include the acceptance of toxic behavior from an individual, inability to respond to a growing threat, or situation where teams/individuals have accepted a way of working that is hurtful/unhealthy to others. It is widespread in the sense that has reached “watercooler status” or a frequent topic of 1:1 so-called scuttlebutt
Context and data can inform a team, but it does not in itself produce positive outcomes. You’re marrying two competencies — to Sense and Respond
Examples of negative effects attributable to scaling and growth include accumulation of technical debt, UX debt, increased dependencies, hardening silos, decreased speed and agility, decreased information flow, disengaged teams, premature optimization, etc. Many of these “costs” are invisible and difficult to quantity which complicates the issue.
Importantly, this can sometimes involve individuals “growing out” of the organization. One could argue that for the benefit of the company you’d like to see a shared growth goal that benefits company / individual, but I’ve found this to be unrealistic and counterproductive expectation (and profoundly immune to intervention).
Continuous improvement involves regular discussion, action, and reflection. Are you addressing the right questions? Are your conversations safe? Are you gathering all available data?

To the 40+ Year Old PMs

Do you stay in the trenches, or get out? Why? And what does this mean for teams?

To the 40+ Year Old PMs

Do you stay in the trenches, or get out? Why? And what does this mean for

teams?

You’re 40+ and involved in product management.

Maybe you took some detours in your twenties and thirties: played in a band (that’s me!), started a business (yup, did that), freelanced to be at home with your kids while they were young, or tri

8 Trends Shaping Modern Product Management