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

How the Sausage is Made

Conventional wisdom: “No one cares how the sausage is made.”  I’m sure you’ve heard this before as well. Maybe it gets followed up with more assumptions: “The consumer cares about the product.  They want the solution.” However, that’s not really true either. They care about their pain. The solution is irrelevant unless the pain is relieved. If you’re really great, you replace pain with pleasure, and build a lasting relationship that your customers are excited to tell others about.

The Sausage

So let’s talk about this proverbial sausage.  When you are hungry at a game and a sausage wrap stand is the only food or you’ll miss the entire game?  No. You probably don’t care about how the sausage gets made. You care about your hunger. You care about the solution. You care about the price. 

Luckily, we don’t live in the local monopoly conditions or restricted logistics of that example.  There are true artists of the craft, solving new pains everyday.

Have you seen how a master chef makes tantalizingly delicious and unique sausage from scratch?  If you love sausage, you do care how it’s made.  You would buy recipe books, watch reality shows, do factory tours, and attend sausage festivals. There is a huge difference between being an artist with a following versus a monolith with a secret. Which company are you building?  Naturally, I didn’t write this post to discuss sausage (though after talking about it so much I’d really love to fry up a batch now).  This is really about sharing your product backstory and software delivery methods. 

Think about a great chef. The kind that writes recipe books, heads up gourmet restaurant chains, blogs about food, hosts a show, and even gets invited as a guest to cook on other people’s shows.

Imagine Martha Stuart or Emeril Legasse teaching their audience about homemade sausage from scratch.  They smile and cook with their pre-measured bowls of colorful ingredients, hand-grinding the sausage.  The sight and sound of the fire, and sizzle of butter in the pan make you certain you’d want to eat not just any sausage – that sausage.  The great chefs care how the sausage was made whether you care or not. They make the best sausage they can and teach others to try their methods even if most people will never bother to make it the same way. 

So, even though what we are really discussing here is either 1) ”no one cares why your product was made” or 2) ”no one care how your software is developed” – I think that’s drastically incorrect. More importantly, when someone says “no one cares how the sausage is made” to me, I know it’s a symptom of something terrible in the prestige economy of the superorganism that could someday bring it to its knees, never to rise again. 

Now we can qualify that old saying…

“No one cares how a faceless factory makes boring sausage.”

Don’t let your factory remain faceless. No matter how boring the boots-the-ground element of your product delivery may seem, those are people who are representing you.  You can either take the Ice Road Truckers and brewery tour approach to your product delivery or you can hide it away. Even the most faceless factories have tour guides. They have a script, sure. This is a marketing opportunity for your customers who are most likely to give a referral. If they show up to see how the sausage is made, give them a taste of the experiments that you aren’t mass-publicizing yet. This let’s you find your early adopters.  That’s a special relationship that you should encourage, invest in, and keep personally engaged.

Go take a tour of a big beer factory and a small craft brewery, compare the two and imagine what a “brewery tour” of your software company would look like.  The big beer companies have a loyal fan base and brewery tours. The ingredients are well-known.  You can even try it at home.  Operational effectiveness, consistency and quality, and reliability are the big beer maker’s keys to success – not proprietary ingredients.

Don’t be afraid to demo upcoming features before they are finished.  Your opportunity to learn and from customer interviews during an alpha release cannot be understated – give them a tour before you make them work for you.  Don’t just make a website, make a fan page too.  Show people you care about what you build as much as they do. Make the digital delivery part of the human dialogue.  As it turns out, you can’t make people get interested in you by yelling “I’m interesting!”  Telling people your product is the best (today) doesn’t say much at all.  Showing them that real people are making sure the product will continue to get better, teaching them what you wish you knew 2 or 5 years ago about the pain you solved and how they can solve it too – then they might be interested. 

“No one cares what the ingredients in the sausage are if they can’t see and hear the artist who uses them, the special process for preparing and cooking it, and insights in why decisions were made.”

The individual lines of code you write aren’t proprietary. Maybe one or two shouldn’t be public knowledge for security reasons.  The rest are meaningless without the rest of the code base and all the people that create viable product-market fit.  Your accounting KPIs, eCommerce analytics, or SDLC aren’t that special on their own either. Your templates are common knowledge to anyone with experience. 

Your people – coming together to do something bigger than themselves -THAT’S special, and while you can lose that no one can steal that. I suspect there are some companies that would never approve a marketer posting a photo of coding-in-progress on Instagram for fear contents of the screen is proprietary. Yet, any developer would tell you that turning frameworks into a worthwhile platform people can reuse is incredibly challenging. No, nobody cares what your product planning meetings or your Scrum process is, unless the people who make it special are front-and-center.  You can make an official statement – like so many companies – that your people are your greatest asset; but when you hide your people and how they work from the public eye, the message is clear, not only to your people but to your customers as well: you don’t take any pride in the sausage-makers, so the sausage probably isn’t that special. 

This is the difference between posting on Twitter “My apple pie is made with 20 apples” versus a video explaining which apples to use and why, the process you use when you pick them out at the store, why you bought them where you did, etc. Teaching the generations coming up behind you makes you matter, not protecting a secret that isn’t even a secret worth stealing. 

“People don’t care how the sausage is made unless they trust you share their love of great sausage.”

The difference between having consumers and having an audience is sharing their pains, pleasures, fears, and passions. Don’t sell to people, mentor them. Don’t market to people, teach them. Is it possible that some people want to know how you make gumbo but not how the andouille sausage was made?  Absolutely.  That’s the line between retention and referral – if you say secret to great gumbo is making the sausage yourself, the real advocates who trust you as an artist and an expert will pay to learn your sausage-making methods.  The opposite is true too.  If you don’t share the passion or demonstrate your expertise, no one is going to listen.  They can spot you as a fake from a mile away.  They know sausage isn’t a priority for you and nothing you say about making sausage is worth sharing with their friends. 

“No one cares how you make the sausage if YOU don’t care how you make the sausage.”

This is probably the most on-point.  Teams who think no one cares how the software is made also don’t have much pride or faith that their process is worthwhile. Sometime the biggest challenge is just showing the engineers how great they are. As the leader, you have to be like a head chef: It’s not just that you love and take pride in the craft, it’s your time-in-the-fire and belief in the process itself that give people the confidence to follow you.  Sure, your customers may not want to sit and watch code being developed for hours on end, but throwing a montage, hosting meetups, YouTubing behind-the-scenes footage, and some exciting reality show commentary is something people love and look for as part of the complete package. That type of messaging let’s people know you care about the work it takes to solve their pain. By giving some visibility into how much diligence, care, and work is put into the next release, your customers can feel they were part of the experience and have a better appreciation why updates and new features can take awhile to release.

If you want the inspiration I had when I wrote this, go read these books:

Rework

Steal Like an Artist: 10 Things Nobody Told You About Being Creative

Show Your Work!: 10 Ways to Share Your Creativity and Get Discovered

Photo via The Digital Marketing Collaboration

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

How to Validate the Problem Statement

Lean Startup Principles – Validate the Problem Statement

Remember when I said that most companies waste money on mobile and that their smart presence makes them look dumber than when they started?  Remember how I said that the Lean Canvas can be used for product roadmap and feature prioritization? 

Let’s dig in to how I’m doing that with Emphatic, the mobile app for sharing physical books with your virtual society.

Now that we have a heartfelt product backstory, let’s build the business model.  You may recall that I encourage the Lean Canvas.  It can be done quickly enough that you can think through multiple possibilities for what the right “Plan A” business model before you start investing time and energy in developing your product.

Lean Canvas Step #1 – Identify Top 3 Problems

“Validating the pain” means two things: 

  • The pain is significant enough that people would pay you for a better way to alleviate it.
  • The pain is shared by enough people that focusing a product on that pain will result in a viable business model.

In other words – “Do I have a problem that is worth solving?”

Brainstorming for Emphatic

Here is the long-winded brainstorming version of the problems. 

Problem 1 – As a father, time to myself when I can read is limited.  When I wanted to Tweet a quote from a physical book or make a quick virtual note about my thoughts so I’d have it later, the process was distracting from the experience of reading the book.  With limited time to read and limited time to write, the inefficiency and ineffectiveness of trying to do both at the same time was extremely frustrating.

Problem 2 – Keeping track of my thoughts and insights is hard short-term and nearly impossible long-term.  I love “book pairing” – I gain more from reading two or more books with topics distinct enough that the synergy between them is worth more than reading the one book alone.  As an example, reading Austin Kleon’s Show Your Work! at the same time as Eric Ries’s The Lean Startup gave me two fairly different but complementary perspectives on choosing what to create (as an artist or writer or worker) and making sure you’re creating something worth the time you spend.  Of course, he drawback if you want to properly attribute/cite your sources (and you should), is that it becomes even harder to keep track of the insights you gain and which author and book should be credited.  As I shared in the Product Backstory, this is challenging enough when I’m writing a short blog post a few days after reading two or more books.  When writing a 30 page thesis with dozens of sources that were found over a 6 month period, this went from challenging to “maybe I should just find some new books instead”.

Problem 3 – Speaking of research papers, the tougher concept to grasp in high school about bibliographies and citations wasn’t the format in which to provide the information (that just takes practice and a handy set of examples).  The painful part was the grey area between researching as a group with your classmates versus “cheating” – too many shared sources looked like you didn’t do your own homework, even though learning and researching as a pair is far more effective than doing it alone.  The flip side of that is the grey area between what you need to cite in the first place – when I combine my philosophy and MBA background with Austin Kleon and Ash Maurya to produce an idea that is fairly unique to me – what do attribute I and when? It takes so much time to properly cite things in double-spaced New Times Roman MLA format that I went ahead and restricted the number of sources to compensate – hardly what my teacher intended!

Get Succinct – Add the Problems to the Lean Canvas

If I was teaching you this in a workshop, I’d get you boil down each problem statement enough that you could write it with a Sharpie and fit it on a Post-It note.  Us workshop peeps do this for two reasons – the rest of the room needs to be able to see it from wherever they are sitting and you need to be succinct.  Thus, the long version up top represents the conversations and musings I’ve had about this so far (like I’d facilitate in a workshop) while below I’ll summarize them.

As Ash Maurya describes in Running Lean, knowing the pains that Plan A will address is important, but its the ability to validate the business plan as a whole – in this case, by sharing the completed Lean Canvas with friends, mentors, or potential customers – that is the real point.  If you can’t explain to a potential customer what pain you can solve for them in under a minute, they probably won’t care about the business model you’re building around their pains.

So here are the Post-It size problem statements:

Problem 1 – Frustration capturing quotes and notes

Problem 2 – Difficulty keeping track of insights

Problem 3 – Grey areas when citing sources

Validate the Problem!

Remember how the title of the post is “How to Validate the Problem Statement”?  You have to go talk to people!  I’m going to head over to the library and ask people who look like they love books about these pains.

Want in?

If you can empathize with these pains, you’re potentially my target customer!  If you’d like to help me solve this pain we share as an early adopter, sign up for the email list here.

Tell a Product Backstory

Scratch your own itch.

Maybe you want to start a company.  Maybe you are at a company but you need to drive a new product to market, with very little guidance on what that product is.  If you are still at the “I bet I can build something great but I don’t know what to build” phase – where I have felt stuck for the last three years – take the advice of Jason Fried and David Heinemeier Hansson, the founders of 37signals (they make BaseCamp):

“The easiest, most straightforward way to create a great product or service is to make something you want to use.  That lets you design what you know—and you’ll figure out immediately whether or not what you’re making is any good.”  Via Rework 

That’s exactly what I’m doing with Emphatic.  Full disclosure, this post is an elaborate backstory for an app!  I write about agile and product innovation, but I’d like to think the product backstory is as topical as the product backlog.  The scope of the MVP isn’t as interesting as why I chose to build it.  After all, software is part of the human social dialogue.  An artifact of our organic will-to-power, collectively, when we come together as superorganisms.

You see, I found my love of writing again with this blog.  I found my love of reading again because I ran out of knew ideas to think through and write about.  

In the process, I found a pain.

Freshly laid off, I knew of a few great books – the source material for other great things I’ve read or seen presented – so I picked them up from the local library.  While reading two of those books, The Lean Startup (Eric Reis) and Show Your Work! (Austin Kleon) – I was frustrated by how difficult it was to get in the zone reading the words on the page fully engaged when I so desperately wanted to capture notes, quotes, insights, page references, other books and authors mentioned, and tangential ideas to look up later.  As a proud millennial, I’ve gotten accustomed to doing everything on my iPhone – emailing, applying for jobs, taking notes, reading news, social media, etc.  I’ve written entire blog posts in the shade of a nice spruce tree using just my two texting thumbs.

So there I was, fumbling with my phone and a physical book and trying not to lose my train of thought or intense focus on the words on the page, I started taking pictures instead.  Thats when it hit me.  This is a pain.  I’d solve it even if I were the only user.  

To go further back, once upon a time, I was completing a philosophy degree and had to read hundreds of pages per week and write dozens of pages per week to show my understanding of complex ideas.  In hindsight, whether in literature or philosophy, the biggest pain has always been attribution and annotation.  I get so consumed by the book that I forget to write anything down for later.  I write it down but forget the page number.  Or I lose track completely of where I found something.

The pain of switching between “reader-response author” and “disciplined researcher” led me to over-compensation – as most people do with a flawed workflow – by separating the two completely!  If proper citations was a requirement, I’d research sources and quotes and build out a bibliography and write whatever I came up with based on my predetermined attributions.  If I was reading Camus for fun, I’d underline and dog-ear the book and never take a note, then write up my thoughts without judgement or attribution! 

In other words, however mundane this pain may seem, is it really a necessary fact of life?  No.  A solution could be created.  So when I see this advice, it really resonates with me:

“When you build a product or service, you make the call on hundreds of tiny decisions each day.  If you’re solving someone else’s problem, you’re constantly stabbing in the dark.  When you solve your own problem, the light comes on.  You know exactly what the right answer is.” Via Rework

All of my time in custom application consulting and delivery, everything I have ever said about agile, innovation, and leadership, is fundamentally related to what they are talking about.  At one end of the spectrum you know the pain personally and need almost no documentation.  At the other end of the spectrum, no amount of documentation will create engagement and inspiration to build the software.

Laura Klein said it like this:

The first tool in any sort of design is truly understanding the problem you want to solve. […] 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 you 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

So while I’ve been Tweeting out product backlog items and I will soon blog about how targeting and user persona validation dictates product roadmap, I wanted to share the product backstory first.  If you can empathize with what I’ve said, you’re my target user.  If you’d like to help solve this pain we share, sign up for the email list here.

Photo via Łukasz Popardowski