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

How to Have Your Marketing Automation and Eat It Too

So you are starting a blog.  Or a company.  Or launching a new product.  Or you’re an intern or analyst somehow tasked with marketing and social media.  Me too.  I’m a couple of those – so we have things in common.  Here’s where I’ve landed so far with Marketing Automation.  Leave a comment or Tweet me @keenerstrategy if you have additional awesome ideas I can try or if you have any questions about what I’ve done.

This entitled “How to Have Your Marketing Automation and Eat It Too” because I have a fundamental impatience with my craft.  I don’t want to wait until the perfect time to publish a post.  I had the thought, I put it “to pen” and I feel closure knowing its OUT THERE.

Here’s what I do:

I use WordPress to write the post and I publish it as soon as its done.  This doesn’t optimize for the WordPress Reader audience, but that isn’t the source of views for me.  It also shares to LinkedIn, Facebook, and Twitter.

LinkedIn and Twitter are the source of my views.

I have IFTTT (IF This Then That) set up to automatically Tweet my post like this:

IFTTTThis way, using the insights from Hashtagify about my target market (people who would want to read about how I “do” product innovation and management) I can automatically add the high-impact hashtags and have Buffer send out the tweet at the time optimized for impressions.

So it looks pretty simple the first time:

After

Then the second time (when it matters on Twitter via Buffer) it has great tags added automagically:

Before

After trying both, I do like Buffer better than HootSuite.  I like the iOS app better, but the real differentiator is that it works with IFTTT – something I use for other fun things and intend to expand because it is awesome.

The other great thing to do with Buffer – because I write about innovation and Tweet posts from TechCrunch – is to use Chrome and the Buffer Chrome extension.

Have fun automating!

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

You have my permission to enjoy your vanity metrics.

I know I talk about valid metrics.  Ad nauseum. I won’t stop anytime soon – and seriously, you do need to get your act together.  That said, I empathize with where you are coming from.  So many numbers yet so little time!

 You have my permission to enjoy your vanity metrics. 

They feel good. When you’re winning, and they seem to scream SUCCESS! 

Getting more Twitter follows, higher site traffic, increasing revenue – focusing on whatever metric makes you feel better about the direction of your product, division, or company can be the little push that keeps you enthusiastic about your work.

I love my vanity metrics too: but this isn’t a “have your cake and eat it too” thing.  This is a “don’t eat cake when you’re dying of dehydration” thing.

So have fun and brag about them – to yourself.  Do not make any decisions based on them.  More importantly, as a leader, don’t let your followers waste time and energy justifying their decisions based on them.  

If you don’t know the one or two metrics that are an actionable, VALID, driver for hypothesis-based product innovation – find an expert who does.

“Managers who don’t know how to measure what they want settle for wanting what they can measure.” – Russell Ackoff

Photo via Luis Llerena

The Lean Startup (Notes)

Here are the notes I took on my iPhone while reading The Lean Startup by Eric Ries.  The difficulty of properly taking notes, referencing the pages, and getting exact quotes was my inspiration for my new app, Emphatic.

That said, enjoy: completely unfiltered or verified. Hope you catch the random Hunger Games reference.

Learning as Ex post facto justification versus a controlled empirical process
It’s better not to give into it. It takes 10 times as long to put yourself back together as it does to fall apart.
Pg19 innovation means learning, which takes controlled failure and is the opposite of efficient
Pg 30 definition of validated learning NOT justification of failure pg 47 conclusions
“Bit by bit, customers tore apart our seemingly brilliant initial strategy.”
Value vs Waste in Validated Learning – what is the simplest, most efficient, fastest way to learn which demand to supply?
Page 50 first to third paragraph
Page 52/53 the audacity of zero reinforces delaying exposure to the truth
54 squandered resources on theatrics instead of progress
Experimenting requires a predetermined definition of success and failure. If you can’t fail, you can’t learn. You didn’t actually test anything. P56

P111 dare you to get your startup idea stolen by a large company
P113 ” successful entrepreneurs do not give up at the first sign of trouble, nor do they persevere the plane right into the ground. Instead, they possess a unique combination of perseverance and flexibility.”
IMPORTANT! P126 – optimization vs learning
135 – comparison of agile team to machines in a factory
144 – guild-based sabotaging, actionable metrics the answer
“The problem with the notion of shipping a product and then seeing what happens is that you are guaranteed to succeed – at seeing what happens.”
Symptoms You Need to Pivot-

Decreasing effectiveness of product experiments

General feeling that the development team needs to be “more productive”
173 – types of pivots
Focus on only one engine of growth:

Sticky – retention, track compounding rate of growth

Paid – advertising, track margin per customer

Viral – word of mouth has an exponential impact, viral coefficient greater than one

P225 – scaling issues and adaptation

You have my permission to enjoy technical brainstorming. 

Technical brainstorming is tempting. Too tempting. Once you have a problem to solve, rushing out to find all the possibilities out there is fun.  It is so fun that it turns into bloated “sprint zeros” and one-year “MVP”s.  Don’t do that.

However:

You have my permission to enjoy technical brainstorming.
My app – tentatively named ShareLighter – has lots of exciting technical possibilities.

The process of bringing the right product to the right people is both art and science. I swear I don’t string together new word groups for intentional buzzwording. I’m learning how to bring an idea to market and sharing it as I go.
Hypothesis-driven backlog prioritization? Audience-first monetization? Analogs and antilogs?
If that’s too many words that you think are just meaningless buzz, I know how you feel. That’s why relationships are so important. Shared experiences.
Once a platform dedicated to highlighting and sharing the most meaningful words of a book is created, the platforms, SDKs, and APIs out there are thrilling to think about! Goodreads, Twitter, Hashtagify, Instagram, OCR, Amazon? It could meaningfully consume and give back so many great things! It gets me excited to read API documentation.

Seriously. All of it.
So let me just say, if you want to start a company and you have great technical chops, especially if your the one expected to wear the engineering hat, I give you permission to get excited about implementation possibilities.
You need an audience full of people can care about and understand as well as a framework for knowing if you’re solving their pains or scaring them away.
But don’t let that steal the joy of learning what you want to learn, as an individual and as a team. Get that 20% time, go down the occasional rabbit hole, experiment, make hackathons as important as your sprint review.
I’ll talk about the importance of building the right thing, but I know you love building it right. So do I. Go ahead, geek out.

The PERFECT Agile Process

THE PERFECT agile process for new product innovation achieves two things: everyone is intimately involved in creating something for a well-known archetypical user and everyone has scientific certainty that the next engineering feat and market risk is a hypothesis that merits experimentation and discovery.

Your agile process doesn’t do that?  I’m not shocked.

If you aren’t sure – how happy are you with answers to questions like:

  • How did you prioritize this feature over that one?
  • Do you really think people want this?
  • Are you sure this is what they asked for?

Most agile implementations are focused exclusively on maximizing the efficiency of 40hrs of develop labor-time.  Like optimizing a car factory for the performance of only one step in the assembly flow – that’s absolutely counter-productive.

Here’s the perfect Work-In-Progress flow:

Idea, hypothesis, commitment, construction, iteration, validation

To further smack the face of convention, I’ll add three claims:

You don’t need testers.

You don’t need estimation.

What we do need is the discipline to know we are building the right thing before we build it, then test that assumption objectively.  This means A/B releases sometimes, cohort analysis, and a clear understanding of the most important metric for each product.  This agile process combines all of my experiences with the concepts discussed in The Lean Startup by Eric Ries, and results in a Scrumban flow best suited for building a culture of innovation.

Let’s break it down:

1 – Idea (Pains to Solve)

The idea backlog is everything feature and improvement we feel reasonably certain will make the product more successful.  This is where we discuss the future.  These start as undocumented epics and end up split into user stories that can be objectively prioritized.

2 – Hypothesis 

An idea gets to the hypothesis stage once we have collaboratively estimated the impact of the feature.  This requires metrics and forecasting.  The work we do needs to be traced via innovation accounting.  If we don’t have an objective, realistic impact number that let’s us know if we built the right thing, we won’t be able to learn properly.  We need ensure we small-batch-ify the features into releasable stories small enough to be code complete in around two days.  The larger the story, the less likely our predictions are accurate.  This is like being the first person who invented cake.  Small changes in variables make the scientific method, even in an art like baking, successful.

3 – Commitment

Pretend there are 7 cards in the Hypothesis column.  Because we have numbers that relate to value and certainty, we can easily prioritize our backlog and complete “Sprint Planning” for the highest-impact cards.  This looks like a hackathon, so whiteboarding, pair-photoshopping, research, and hackathoning is completed.  When we are confident we are building the right thing and that we know how to build it, we commit to our users what is coming up next for them.

4 – Construction

We pull cards into construction while we are building them.  We are creating and coding, answering two questions as we go as new ideas come up.  Is this realization something essential to our hypothesis?  Can this wait until later?  We want the construction process to be collaborative and insightful. 

5 – Iteration

When we’re done coding, we review the working software as a group.  This isn’t manual testing, this is more along the lines of “Two likes and a dislike”.  If we see a defect or have an improvement, we ask the two questions for each thing – Is this realization something essential to our hypothesis?  Can this wait until later?  We want to remove “contaminants” from our experiment at this stage without changing the hypothesis.  For example, if a different shade of blue will improve readability so much that we think NOT changing it will invalidate the hypothesis, let’s change it.  If we think the user would like to choose the shade of blue, that’s a new idea and its added to the backlog.

6 – Validation

Our definition of done requires that we validate the hypothesis.  This is done with product metrics, social listening, and customer interviewing.  If we prove our hypothesis we should ask “Can we do more?” and brainstorm how to continue to reap the benefits of the new feature.  If we disprove our hypothesis, we know we didn’t build the right thing and our retrospective (and customer interviews) should ask “Why didn’t this feature achieve {hypthosis xyz}?” and “What did the user want instead?”

What we won’t do:

We are purposefully avoiding what I call “guild-based agile” – a process flow that encourages functionally-distinct steps and hand-offs.  I don’t want the engineers to optimize their coding output or designers to optimize their number of deliverables or analysts and testers optimizing their little area of concern.  I know that mini-waterfall makes you feel more productive.  I’ll help you show your work to the world in a way that makes that urge irrelevant.  I want well-rounded creators who build a relationship with the people who use our product.  The number of features added is less important than continuous innovation and deliberate empirical product development.

Now – Let’s challenge my claims:

You don’t need testers – In guild-based agile, where the step each card follows relates to a functional division, testers are the natural last step.  Here’s a flow I’d never use – Requirements, Creative, Estimation, Coding, Testing, Done.  The goal of a push-based workflow is for each step to maximize its own productivity.  For a creative person, this means designing a large batch of screens all at once, iterating on their imperfections, shipping them off, and avoiding distractions from developers who don’t understand the designs.  The same is true for each step in this dysfunctional process. 

The presence of a tester is the symptom of immense process waste.  A collaborative team creates with ideas, imagery, and code simultaneously.  Collective genius around a goal – We will solve pain X for user Y by building Z – is more valuable than individual contribution.  Guild-based agile encourages alienation and destroys creativity.  As the batch size grows, getting things done quickly becomes prioritized over questioning “Are you sure we built the right thing?”

Having every function encouraging each other with real-time feedback, focused on the user, reviewing the working software together, and taking pride in the product is far more effective.

You don’t need estimation – Remember when I said all the cards should be about two days of work or less?  Remember how the card isn’t done until market data is reviewed and the success of the card hypothesis is validated?  You don’t need estimation, because you can simply count the cards.  You can forecast based on cycle time.  From the time we have an actionable hypothesis, how long does it take know if it proven or disproven?  The WIP limit depends on the size of the team and should be empirically adapted.  The moment someone feels they don’t have a real sense of empathy for the user of a story or its unclear if you’ll know whether or not your work is valuable – slow down!

It’s true for every function, no matter how specialized the cross-functional team becomes.  Don’t make more designs once the hypothesis column is full, do marketing and surveys on what you have, walk through each build with the developer to discuss new ideas.  If the validation column is full, don’t code anything else – confirm if the right things are being built before building anything else.  I have a hypothesis, of course, but I’ll share that later.

My First MVP.

Notice the blank spaces.  Notice the technological wonders that – despite my imaginative artist-engineering mind, you’d never actually see.

Tentatively Entitled – ShareLighter

Product Vision

Do you love reading physical books, but wish it were easier to share the insights you’ve gained and quotes you love via social media?  

Value Assumption

People want to share quotes from physical book pages with virtual highlights, blackout, or underlines as a form of expression. Someone – somewhere – in the fantastic conversations that grow from this narrative of noting, quoting, and sharing, wants to pay to be a patron for this game of reader-response, learn it and share it, cultural-criticism-gone-viral.

Growth Engine

Viral. People will love the app enough to share it with two or more friends. 

Success Metric

Viral coefficient, tracked by release version cohort analysis. If the viral coefficient is increasing, the cohort is correlated with the newest features, indicating they have tentatively proven their success hypothesis. 

Minimum Viable Product

To establish our baseline, we need the core functionality of taking a photo, highlighting text virtually, and sharing the photo with a caption to a social network.  To track our success, we will need an “invite friend” feature and the ability to correlate the act of inviting to the version of the app. 

“Blue Sky” Potential Features

You’ll have to see the Trello board…

Do you care?

You have other ideas, because you want this app too, right?  @mention me on Twitter for glory or shoot me an email. andrewthomaskeenermba@gmail.com 

Failing Better to Win Sooner

I interviewed some time ago for what would be my third role in product management in the custom app development space.  This form of “consulting” means I have to be a product visionary on behalf of someone else.  They have ideas and money, we have implementation practices and great engineers.  This interview, like in the pre-sales process of my previous two companies, required I take a backlog, prioritize it, define the Lean Startup -style MVP, and justify the release plan for future enhancements.

Obviously, I have asked, or been asked, in the hundreds-of-times range, “what is the Minimum Viable Product?” and frequently the answer is “all of it”. 

As the bard said, Therein lies the rub. 

The more important question is – “Minimally viable for what?”

I have yet to see a project plan or feature list that included valid success criteria, or any definition of how user stories should be prioritized, or features that would support cohort analysis or A/B testing.  Once, I even heard a CEO speaking of the immense importance of measurable success, only to have the head of operations and the head of sales immediately undermine him with the claim that staying under budget and releasing on schedule were okay success metrics – and the CEO nodded!

The Lean Startup has a clear definition of what the MVP must be minimally viable for: tuning the growth engine that keeps the business alive. 

That means the MVP builds a baseline for testing your hypotheses. 

Unfortunately, what is really missing is the lack of vision and discipline needed to do this.  No matter what you are building, it either solves a problem that makes people want it or it doesn’t. Without the ability to know if each feature was the right feature, the product is not viable and your business is not sustainable, and no amount of minimalism is sufficiently minimal – you’re still just wasting money. 

So in my spare time, as my pet project, I’ll show you how to do it.  How lean is my startup going to be?  $0 invested.  My first product solves a real pain that I have. I know that the demand for this pain to be solved is increasing. I would solve this pain even I was the only user

Enjoy the ride.