Entrepreneurial Product Ownership

As a Product Owner, is “entrepreneurial” or “innovative” in your job description?  Yeah, I thought so. But what does that even mean?

As I’ve mentioned before, the ability to ensure work is meaningful to the user-in-pain and the customer paying to resolve that pain (occasionally but not always the same person) is super important to the health and motivation of the engineers. The shorter the time between empathy and resolution, the more meaningful the work, the more likely the direct correlation with revenue, and the safer the jobs and projects of the engineers become.

The big “evil” business “side” in a large company doesn’t need any of that in order to maintain risk aversion and product agility. Cancelling a three year project before a customer saw it because a better project was two years in WAS their agility.

Congratulations on your agile transformation, but when you said “agile” you really meant lean concepts like “small batching” and “level-loading” and “systems thinking”. As a Product Owner, you must obtain a clear understanding around lean startup principles. That may shock you. Alas, the moment your team became an agile team, you became a new venture.

At scale, as a Product Owner overseeing delivery of your backlog, it is of tantamount necessity that you strengthen your relationship with your Product Manager. To the extent the Product Manager handles budget approval from the C-Suite on your behalf and builds up buy-in from your top customers, treat them like a venture capitalist with many connections in the VC/Angel community – and this is your first company. The expected return is 10X due to the extra risk. Many of them are having to let go against their will and trust that you know what you’re doing.

Within this context that you bear on your shoulders, the burden-of-proof that the budget can be trusted to the agile engines of production, you now have to proactively validate all learning about three things:

Product risk – The right thing was built to solve the pain of a large (enough) but narrowly (enough) focused group.

Market risk – The ability to build and continuously improve the viability of your product’s business model.

Customer risk – The ability to get the solution into the hands of the customer.

You are the single point of failure for information flow about your product backlog.

Project risk, as you once knew it, is gone. In fact, waterfall was the good ol’ days for the free riders and career passive observers among us. That was part of a bubble in the economy. SO long-lived that it caused no pain to investors, so you never heard it called a bubble. But the era of software-in-itself as a competitive advantage is gone. The fat shall be trimmed.

So no, you don’t have a deadline to track against but you do have the angel investments from your Product Manager(s). Also, you don’t really have “technical risk” anymore right? Come on, there isn’t much that you can’t build because most of us aren’t so imaginative that our requirements are science fiction. The risk that your estimates were wrong is so tertiary that some groups do away with it entirely.

No no no, YOU, my Product Owner friend, risk the loss of intrapreneurial “investor” confidence… the confidence that you know what you’re doing, mostly. Can good forecasting and transparency help? Sometimes. Unfortunately, some of us get promoted from T-Ball to the Majors with no notice that it even happened. We need a pocket-MBA and a time machine to make the new demands reasonable.

What can you do?

OWN your own destiny. The path to autonomy, mastery, and purpose is a purposeful pursuit of excellence in your craft.  If you don’t love agile, you may start to. If your boss hates agile, you’ll win her over. But it’s on you to make it happen. 

There are three “steps” to excellence in Product Ownership. Repeating these steps will take your abilities to the next level.

Step One: Establish Communication and Discovery Ceremonies

Agile transformations seem to fizzle at your level (the Product Owner). That’s because the Scrum ceremonies of the builders “under” you are well-established and grow from the ground up. They have become so commonplace that refusing the development team’s desire for a Sprint Retro seems just silly. The ceremonies that keep the team moving are established – the ceremonies you hold with your stakeholders, not so much. Without knowing the stakeholders and the meetings you already have with them, giving specifics here is hard. But – for whatever problem you’re having, looking outside your company. There is a vendor in the services industry that overcomes your challenge as a full-time business model. Prioritizing a longer term roadmap, creative brainstorming sessions, Lean UX workshops, Lean StartUp coaching – large companies have had the problems you’re facing for a long time. Look for a consultant, google what they offer, read blog posts, attend MeetUps. They are excited to talk about what they do. They know that they have to “out teach the competition” to be seen as the expert. Reach out to me for specifics. At the end of the day, borrow those workshop tactics and meeting agendas, get buy-in from each stakeholder, then establish a cadence for those activities.

Step Two: Pursue Cross-Functional Team(membership)

Never stop learning. Create a plan. Get a mentor or friend to share it with and if possible include it in your check-ins with your manager. As a Product Owner, you are the conduit between nearly every other function. Because the “development side” has begun fighting toward cross-functional teams, it’s critical you develop cross-functional communication skills. A simple way to get started is to ask people what they think works best about their jobs. An even more robust strategy is to list out all the job titles of the people you must successfully communicate with, check online for a job description, pick a skill or requirement and prioritize a backlog skills to learn. Should you master photoshop? No. But a few YouTube tutorials as you play with GimpShop (a free alternative) will be a real eye-opener. Remember this isn’t about becoming a jack-of-all-trades, this about mastery and excellence in your product innovation and delivery ownership role. Sharpening your ability to translate between specialists and clarify your intentions about prioritized effort IS your specialty.

Step Three: Define The Art and Science of Prioritization

I’m writing about this quite a bit else where. Check my blog posts, follow any links I gave and come up with your approach. If you need more specific answers, reach out to me.

The Virtue of Scientific Discipline

This is part of a series on the key virtues of excellent Product Ownership.

The Virtue: Scientific Discipline 

I admit, this one combines a few qualities that make someone’s approach to problem solving incredible. The excellence of scientific product innovation requires the ability to identify and challenge assumptions in isolation so that purposeful experimentation and learning can occur. To succeed at disrupting a market, there is a permanent restlessness and curiosity, a willingness to challenge the status quo. The discipline part requires an understanding of what to measure, how to measure it, and the patience to consistently track and communicate your findings.

The vice of deficiency here is a total lack of experimentation. Say “no” to 99% of requests that don’t fit your vision or serve the longer term goal, absolutely; but if you say “no” to 100% of ideas that come your way, focus on locking things down and playing it safe, you’ll destroy any chance of innovation and your customers will abandon you. As Product Owner, it’s assumed that you are controlling a continuous stream of changes. Passively following an original plan or passively fulfilling stakeholder requests is a lack of experimentation of your own. If you don’t insist on tracking the results of their ideas, you’re also just plain unscientific. Empirical process control (Scrum) implies learning through purposeful experimentation. As the Product Owner, your laboratory is the product-market fit and your target result is the sustainable viability of your (Product) business model.

Of course, the vice of excess here is uncontrolled chaos. Drastic changes without rhyme or reason do not lead to adaptation. Evolution takes the discipline to kill tiny bad ideas as they fail and build on the successes. In Scrum this is an unfortunate use of “super-epics” like “LETS DO SOCIAL!!” Adding 7 social networks at once to a product is the undisciplined throwing-spaghetti-at-the-wall chaos I’m talking about here, and it is inevitable when you separate market planning from development planning. As soon as the developer don’t seem overwhelmed by the size of the backlog, stakeholder start feature-stuffing so they don’t feel like agile means “paying people to sit around”.

So the virtue in the middle that is absolutely essential as a Product Owner – whether you are an entrepreneur with a 5-person Scrum team or you are in the middle of a 5,000-strong software-at-scale enterprise – is scientific discipline feast or famine, insist on controlled experimentation not chaos. Insist on purposeful validation of each hypothesis, not hand-wavey assumptions. Insist on actionable metrics and clear articulation and confirmation on whether the product is progressing correctly.

Because you are the single point of failure for information flow, only you can courageously take a stand before things are out of hand. Stay disciplined and rational, but enjoy creative experimentation.

The Virtue of Sincere Honesty

This is part of a series on the virtues of excellent Product Ownership.

The Virtue: Sincere Honesty

Sincerity – the quality of being free from pretense, deceit, or hypocrisy.

As a Product Owner, you are the conduit of an immense amount of information. You are the tip of the spear for what gets built next, which requires you to establish – with your stakeholders, peers, customers, users, and cross-functional development team members – that you can be trusted. In most organizations that I have spoken with, the Product Owner is the single point of failure for information symmetry. Does the Product Manager know what the ScrumMaster knows? Does the UX designer know what the Social Listening Analyst knows? Does the development team know what the customer knows? The duty to prioritize the backlog is derivative. The core purpose of Product Ownership is to prioritize the flow of information.

This isn’t about keeping stories straight or “transparency” and it definitely has (almost) nothing to do with deadlines. Your Product Manager or equivalent stakeholder must trust that you prioritized the right things to build or you’ll lose their “investor confidence.” The customer must trust that you are giving them their money’s worth. The developer must trust that you know the user and their needs and have told them the right thing to build.

So this is about the visibility of information, and your role in promoting the most important insights for each party.

The vice of deficiency is not “lack of documentation” any more than bad product performance is due to lack of velocity. There are no documentation or utilization problems, only communication and engagement problems. So the real deficiency is lack of effective communication of ideas. When you are apathetic but your words scream “ASAP!” that’s hypocrisy and people know it.

The vice of excessive “honesty” is what most people do in the name of transparency: Over-supply of data with no context or prioritization. Just like the overwhelming number of things that you could build make prioritization the cornerstone of managing the backlog, the overwhelming amount of information that could flow through you requires prioritization of what you communicate.

The virtue, in between data-forwarding without context and insincere platitudes of precision and urgency, is sincere honesty – providing the information that you believe is most important to the success of everyone involved. Whatever tool or process you need, be authentic, be genuine, and do your best.

Backlog Prioritization Methods

This week’s learning focus: develop an approach around facilitating the great “How We Prioritize the Backlog” discussion that can be used as a workshop in lean-agile scaled transformations.  
While I have my own preferences and have heard a variety of approaches recommended, it seems the “how to tailor it to your context” is a missing piece.

So if you are part of a group with multiple Product Owners, Product Managers, and other important stakeholders involved in your prioritization decisions, here are the best links on the topic so far. Full write-ups on connected topics and pragmatic recommendations will follow!

Agile 42’s Lean Canvas Method
http://www.agile42.com/en/blog/2013/04/11/lean-project-canvas/

Pragmatic Marketing’s Why ROI Won’t Work
http://pragmaticmarketing.com/resources/why-prioritizing-your-agile-backlog-for-roi-doesnt-work

SAFe WSJF



http://scaledagileframework.com/wsjf

Blog Post that Combines the thoughts above, though it’s so academic it may not be actionable to agile first-timers
https://blogs.versionone.com/agile_management/2014/10/30/agile-prioritization-a-comprehensive-and-customizable-yet-simple-and-practical-method/

How do you prioritize you backlog?
andrewthomaskeenermba@gmail.com

Photo via Rework. Read it!!

Scrum Backlog Prioritization

“Portfolio management is the art and science of making decisions about investment mix and policy, matching investments to objectives, asset allocation for individuals and institutions, and balancing risk against performance.” – Investopedia

How do you manage your backlog?  The strategists at the top are often accustomed to trusting their gut, while the engineers below insist on absolute scientific certainty.  Handing priorities down that game of telephone is a circus side-show of bull whip effect and sociopolitical contract theory.

Not that it doesn’t work out just fine….

Meanwhile, accountants and financial analysts, with the help of algorithms, benchmarking, and actuaries, have been tracking the present value of an asset, mid-investment, with all risks taken into account for a VERY LONG TIME.

The real question is, do you need all that certainty?  Should you be focusing on human interaction and the existential plight more?  I guess that’s a separate discussion…

I mean, at one extreme, do you care about your customers so much that you feel an ethical duty to fix every little bug no matter how much it costs you, your employees, and the families they feed?

At the other extreme, do you love churning out features so much you don’t care how many of those features aren’t wanted or how unsustainable your product has become?

No, I assume neither of those are you (I hope).  Instead, you are trying desperately to strike a sensible balance that lets you sleep at night while feeling good you pleased a small group with their favorite feature.  You’re really in the business of political and emotional backlog prioritization.

I want to let you know that I’m okay with that.  Relationships and society and worth building.  That said, when you are the bridge between the c-suite and several thousand staff member salaries, you may want to find ways to think harder about whether or not you are building the right thing, at the right time, for the right reason.

Thus, I will give you some science on backlog prioritization, but I wanted to let you know that I completely understand where you are with your current methods.

The Lost Product Owner

The Lost Product Owner

At scale, the “Hero-Scrum” paradigm falls apart.  A product becomes too large for one team, then the number of teams becomes to large for the Product Owner & CEO model to work.  A company working toward agile transformation could slowly restructure toward mini-CEOs; but the truth is, the organizational switching costs are too high to make this a realistic option.  Be honest – those that own the customer relationships and those that own the technical communication are, respectively, too specialized – and great at their jobs – to start mashing them together as peers.

That said, I see a clear skew in agile transformation consulting and especially entry-level Scrum training toward protecting the team against the more powerful Product Owner.  While this may be a tactical prejudice when the role is played by your boss, my first-hand experience has been the opposite.  In scaled transformations, the more likely scenario is that Business Analysts,  Project Managers, Jr. Product Managers, Quality Assurance Analysts, or Support Engineers of the organization are asked to rise to the occasion and somehow, instantly and powerfully, lead a team to greater autonomy, mastery, and purpose.

{inspirational anthem plays in here}

Let’s be real.

The two fundamental hero images intrinsic in most Scrum courses – the ever-vigilant, time-protective ScrumMaster and available-part-time, drunk-with-power Product Owner – is meaningless in the more complex patterns of large organizations.

After studying LESS, SAFe, and Lean Enterprise theory, while speaking to representatives or directly working with several dozen organizations, it is clear that there are enough job title “Product Owners” that more attention to the profession (in separate consideration from the role) is a worthwhile pursuit.

Although I initially wanted to pursue the shock value of entitling my first book AGILE IS DEAD: HOW TO GET WHAT YOU MEANT YOU WANTED – it is plain to me that the audience for that book is too poorly defined, the pain is therefore not shared by the entire audience, and the text would be a fantastic (agile) train wreck.

Instead, I can see there is a compelling need to teach the lessons many of us learn the hard way then become agile coaches and lose touch with.  There is a very large guild of professional Product Owners that need hands-on tactics for not only how but why specific practices work well in an agile, lean, scrum setting (as part of a larger enterprise).  Amazingly, many of the hardest questions for running agile trains have analogs with well-established practices in professions and industries so antithetical to innovative software development that we all collectively forgot to look (and our executives understandably would never pay the handful of thought leaders who were looking to come give us a PhD in the topic).

So be on the lookout for the table of contents, the rough-draft blog posts, and the invites to MeetUps and workshops.  I’d love to hear from you on the topic in advance of those things – so reach out to me at andrewthomaskeenermba@gmail.com

Photo via Jaxon Stevens

Winning Product Ownership Tactics

Editorial note: My blog’s ScrumMaster let me know that this post was a super-epic with poorly-defined target user personas, so I will decompose this into more actionable User Stories.  I’m leaving this draft in place because I want my Product Owner followers to know that it’s okay to admit you didn’t size or prioritize things right the first time…be genuine.

So now you’re all agile…

At scale, the “Hero-Scrum” paradigm falls apart.  A product becomes too large for one team, then the number of teams becomes to large for the Product Owner & CEO model to work.  A company working toward agile transformation could slowly restructure toward mini-CEOs; but the truth is, the organizational switching costs are too high to make this a realistic option.  Be honest – those that own the customer relationships and those that own the technical communication are, respectively, too specialized – and great at their jobs – to start mashing them together as peers.

That said, I see a clear skew in agile transformation consulting and especially entry-level Scrum training toward protecting the team against the more powerful Product Owner.  While this may be a tactical prejudice when the role is played by your boss, my first-hand experience has been the opposite.  In scaled transformations, the more likely scenario is that Business Analysts,  Project Managers, Jr. Product Managers, Quality Assurance Analysts, or Support Engineers of the organization are asked to rise to the occasion and somehow, instantly and powerfully, lead a team to greater autonomy, mastery, and purpose.

{inspirational anthem plays in here}

Let’s be real. 

The two fundamental hero images intrinsic in most Scrum courses – the ever-vigilant, time-protective ScrumMaster and available-part-time, drunk-with-power Product Owner – is meaningless in the more complex patterns of large organizations.

So here are the top three winning tactics that can help mid-senior managers and individual contributors succeed.


#1 – Startup Principles are Worth Your Time:

As I’ve mentioned before, the ability to ensure work is meaningful to the user-in-pain and the customer paying to resolve that pain (occasionally but not always the same person) is super important to the health and motivation of the engineers.  The shorter the time between empathy and resolution, the more meaningful the work, the more likely the direct correlation with revenue, and the safer the jobs and projects of the engineers become.

The big “evil” business “side” in a large company doesn’t need any of that in order to maintain risk aversion and product agility.  Cancelling a three year project before a customer saw it because a better project was two years in WAS their agility. 

Congratulations on your agile transformation, but when you said “agile” you really meant lean concepts like “small batching” and “level-loading”.  As a Product Owner what you really must have is lean startup principles.  The moment your team became an agile team, you became a new venture.  You now have to proactively validate all learning about three things:

  1. Product risk – The right thing was built to solve the pain of large (enough) but narrowly (enough) focused group.
  2. Market risk – The ability to build and continuously improve the viability of your product’s business model.
  3. Customer risk – The ability to get the solution into the hands of the customer.

Project risk – as you once knew it – is gone.  You don’t have a deadline to track against, you have angel investments from your Product Manager(s).  You don’t have technical risk that your estimates were wrong, you risk the loss of “investor” (c-suite, VPs) confidence that you know what you’re doing.  Can good forecasting and transparency help?  Sometimes.  Unfortunately, some of us get promoted from T-Ball to the Majors with no notice that it even happened. 

Product Owners – strengthen your relationship with your Product Manager like they are the venture capitalist and this is your first company.  The expected return is 10X due to the risk.  Many of them are having to let go against their will and trust that you know what you’re doing. 

Key skills to learnThe Lean Canvas, Innovation Accounting, Validated Learning


#2 – Everything is Marketing:

There is a java team, and a product management team, and an inbound sales team.  Marketing is not a department.  In a large company, yes, there is a corporate group in charge of advertising, branding, messaging, and copy.  As a Product Owner, embrace the idea that the marketing team is only 1% of the marketing the company does.  Everything is marketing – and you just became a sales(wo)man.  Every time you let a critical defect through and an engineer complains to their spouse and their spouse bad-mouths the company to their friends at a cocktail party – that’s marketing.  The world is a small town.  What you do matters and nothing is in the shadows.

Treat memos like Tweets with a million followers.  Fake your own notoriety if you need to.  As it turns out, you are uniquely positioned to make an enormous difference in how effectively your team meets the needs of customers.  Luckily, you don’t have to just make that stuff up from scratch!  Other people at other companies in roles you never thought to cross-pollinate against have ESSENTIAL skills that are PROVEN to work.  Decades old.  Seriously.  And most of them give that training away just to get you to spread the word!

Key skills to learn:

  1. For Roadmap / Release Planning – Talk to a Custom App Dev guy.  I can make intros if you like.  Most of them are so desperate for attention, you could make up a fake product and string them along for months.  Anyway.  The good ones do Story Mapping and MVP scope for FREE as PRE-SALES.  Lucky you – you already have a product manager to building software for!  You still need to be consultative to ensure collaboration and rational planning occurs.  Same advice as your personal life.  Date your spouse.  Start the courtship over again occasionally.  Things have changed, don’t act like you’ve memorized everything and communication can stop!
  2. For Stakeholder Alignment – Study the super hot topic of starting your own company.  You’ll be glad you did.  On ramps.  Assumption mapping.  Balanced scorecards.
  3. For Sprint Planning – Its a solution pitch.  PLEASE have an agenda.  PLEASE gain all necessary information and buy-in for prioritization prior to involving your developers.  Want an example?  Google “SAP Digital Transformation” and you’ll see that they have an example solution pitch for every industry.  This isn’t new territory you’re exploring, just a new town with a new bar but your old friends came with you.e
  4. Sprint Reviews – There is an art to the tell-show-tell demonstration.  Engineers and engineer leaders can be especially bad at this (and I’ve learned from plenty of terrible webinars as well).  The attitude “you paid me to build it, look its right here, no questions?  great….” is going to erode whatever influence you aspire to have.  Tell your stakeholders what you accomplished.  You know, business goals.  Product Pirate Metrics.  Tell them why it matters.  You know, to revenue and the sustainability of the business as a whole.  Give them numbers if you know them. Then anchor your demo against a pre-defined roadmap.  Lead feedback as you go with open ended questions.  Follow the poll / show of hands, individual follow-up routine.  Most importantly, this means taking it seriously enough to prepare in advance.  Everything is marketing!
  5. Sprint Retros – Until you start making falsifiable hypotheses, you have no experiments.  Without controlled changes to variables, you are not engaging in empirical process control.  You’d be amazed what a 4th grade poster about the Scientific Method could do for your team.  Test at least two assumptions “changing X in the product will influence Y positively” and “changing practice A as developers will impact outcome B as a team”.  There is no learning without defining what a successful outcome is prior to conducting the experiment.

#3 – Show Your Work (Too):

No really, make a scene.  Draw a picture.  Use a kanban board on your wall.  Write haikus.  Whatever you do, show it off in progress.  Disappearing to document things makes you irrelevant.  Show people what you do, how you do it, and why you do it – aspire to be like the great chefs.  You might even realize that people actually care how the sausage is made.

The best way to do this is to teach others.  The only way to build cross-functional teams in an ultra-specialized environment is to show people how much it benefits them to become cross-functional team-mates. 

If you don’t have time (you think) for reading anything intense, just pick up some Austin Kleon.  Savor it slowly.  Sip it.  Like egg nog.   Then tell people the compelling secret to the best homemade sausage anyone every made Tuscan soup with (metaphorically, of course).

Agile is dead.

Agile is dead.  Not the way your goldfish dies as a kid.  “Agile” is dead the way Marxism (as a socioeconomic political stance) is dead.  The dilution of the meaning of the word through excessive use, improper use, and deconstructionism, has made it not-worth-speaking-about.

Pragmatically speaking, there are really two ways people killed “agile”:

  1. As part of a movement, several institutions adopted the language of agile without changing their structure, values, or goals.  This made it necessary to explain your use of the word agile.
  2. Many of the practices that made “agile” marketable have become the normal way of developing software due to market demands, even in companies that expressly claim they will never practice “agile”

That latter disconnect is why you’ll see I’ll still write about things that sound like “agile” as a noun, the kind consultants charge money.  I’m going to be more specific about how innovate new products, encourage logic in product management decisions, and help you not destroy the team that makes you successful.  As dave Dave Thomas, one of the original authors of the agile manifesto said:

Agile is not a noun, it’s an adjective, and it must qualify something else. “Do Agile Right” is like saying “Do Orange Right.”

Having built my career around agile and scrum, the dread I began to feel roughly six months ago when someone started talking to me about agile in software development was meta-disheartening. 

Now, instead, I’m beginning to see that getting very specific about what I would improve in a company’s strategic planning, management tactics, and organizational psychology is extremely important.  After all, when was the last time that you used “agile” the noun-and-buzz-word-for-sale in the same way you used “agile” the adjective?

ag·ile

adjective

1.able to move quickly and easily.

“Ruth was as agile as a cheetah”

synonyms: nimble, lithe, supple, limber, acrobatic, fleet-footed, light-footed, light on one’s feet

Does that sound like your company?  Does it sound like your software team?  Product strategy?   Only if you are small, most likely.

If you work at a very large company, I have a hard truth for you.  The nimbleness of a body with extreme mass is internal. In a startup, you cancel a feature when it has a detrimental impact on a key metric.  Choosing one feature over another in a new product can pivot you into an entirely new competitive landscape, target market, and revenue stream.  In a very large company, you cancel the entire project.  You lay off an entire division.  You sell off everything tangible about the business process that are no longer part of your corporate strategy.

Remember how I said Marxism is dead?  Do you hear much about communism as a US social movement?  What about socialism?  Probably not.  Instead, in the ongoing internal dialogue of the USA superorganism, opposers and supporters alike rallied their opinions and held debates and made decisions using the words from the movement until the original words no longer accurately described the problem at hand.  Now socialism is part of our capitalism and capitalism is part of our socialism.  The only people who really care about the words as they were originally meaningful are the people either using them as a weapon or avoiding them out of fear of it hurting their reputation.

So when I stop fighting for “agile” don’t worry, my core values didn’t change.  I’m just targeting the problems more specifically, empathizing more with the people affected, and resolving their pain directly rather than fighting for revolution.

Here are a few things to do right now that will make your company better:

  1. Plan your business decisions (project-based investments) in smaller increments.
  2. Decompose development tasks so that they are less than a week of coding.
  3. Require continuous code integration (and pull-before-you-push, etc).
  4. Empathize more with users, and show your early adopters your work-in-progress.
  5. Ensure division of labor – “specialization” – isn’t leading to alienation.

 

Photo via davide ragusa

That’s Solutioning!

That’s Solutioning!

“Pain-Driven Design” is a great name for the discipline required to build the right thing rather than building the wrong thing the right way. Laura Klein defines this methodology in her book UX For Lean Startups, which you should add to your reading list.  “Pain-Driven Design” captures perfectly the heart of how product innovation needs to proceed when following the principles of the Lean Startup movement. Be forewarned, it is simple to understand but requires enormous discipline.  I have seen it done very poorly or completely disregarded by dozens of companies of all sizes. 

The steps are:

  1. Validate the Person – Be specific about the person you are planning to help (as an archetype and anecdote for a sufficiently large audience of people with behavioral patterns in common).
  2. Validate the Problem – Understand the pain experienced by the person in step one.  Listen to them.  Watch them.  Learn from them.  If you already have a product, learn what they hate about it.  If they use your competitor’s product, learn what is imperfect about the way it solves pain for the person.
  3. Hypothesize the Solution – Now you think up a solution.  Once you have a specific person to empathize with, communicate with, and build a relationship with (as a representative of a group called a “target market”) you can truly understand their pain and address that pain.
  4. Validate the Hypothesis

Of course, I entitled this post “That’s Solutioning!” so let’s start over at the problem phase.  The reason most product innovators fail at solving pains is that they are too busy solutioning to notice all the pains in the first place!  While facilitating groups in enterprise software customization, I saw this all the time.  The discipline required to truly analyze the pains and painful inefficiencies locked away in a workflow – physical or virtual, while shopping or at home or on the job – is tremendous when we are all so excited to get our ideas out there!  I had a colleague who could jovially point right at someone and say “That’s Solutioning!” to keep the group on track.

Obviously (in retrospect), when I wrote about my perfect agile processI glossed over the critical difference it makes to empathize with a real person to understand their pain.  This is the test every “idea” in the Idea Backlog needs to pass prior to validating hypotheses, experimenting, or developing anything. 

It was nice to see I’m not alone in thinking this way:

The vast majority of time I talk to entrepreneurs, they present me with solutions rather than problems.  They say things like, “I want to add comments to my product,” not “My users don’t have any way to communicate with one another, and that’s affecting their engagement with my product.”

By rephrasing the problem from your user’s point of view, you help yourself understand exactly what you are trying to do before you figure out how to do it.

– Via UX for Lean Startups by Laura Klein

This is the part of Product Ownership – more specifically, backlog grooming, prioritization, and decomposition – that ought to happen prior to Sprint Planning.  This is part of the “half her time with stakeholders” that should occur. It should be a significant amount of effort ensuring the market risk of building the wrong thing is overcome prior to mitigating the technical risk of the team’s ability to build the feature or the project risk of aligning resources and timing.

Here’s how to know an idea, an epic, or a user story has failed the Pain-Driven Design process:

  • If I say my target user is “women with an iPhone” then I’m not being specific enough.
  • If I state my solution without a problem then I’m not empathizing enough.
  • If I build a feature without empathizing with a person, my work is meaningless and my solution cannot be properly validated or a source of disciplined learning.

Imagine a bridge.  Everyone else who read this probably imagined a slightly different bridge.  What you most likely did not do is imagine a person who experiences pain crossing a river.  However elaborate your imagined bridge was, however perfect your engineering certainty about its development you may be, however robust your process for ensuring timeline and budget – that bridge is meaningless on its own.  That is the essence of solutioning: a decontextualized answer.

Do this instead.  Imagine a mid-twenties mother of one on the prairie in Kansas during the 1870’s.  Imagine a stream, only two feet wide but ice cold.  She jumps over this stream on her way to town, holding her child, husband by her side, every Sunday.  As the child grows and becomes heavier, jumping over the stream becomes more painful.

Now you have context.  Now you have a User Narrative and a person to empathize with.  There is a real pain that you can solve.  You can write a meaningful user story in-context: “As a mother on the prairie, I want a foot-bridge I can cross on the way to town because I’m starting to experience back pain that might hurt my ability to support my family’s health and well-being.”

Contrast that with an eCommerce executive yelling “We need SOCIAL!”

Don’t be that guy.

 
Photo via Kevin Sequeira