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