Connecting the Dots

A couple weeks ago when Steve Jobs announced his retirement, I did a little research to try to sum up my takeaways from his success.  One of his stories was about taking a calligraphy class in college, and how that class gave him enough knowledge in the subject to create font sets in the first Apple products (which were later copied by Microsoft for Word).   At the time when he took that class, he had no idea how or why that class would be useful. Only when Jobs looked backwards he was able to connect the dots.

Jobs’ belief that ‘you can only connect the dots looking backwards’ struck me when I heard it, probably for the same reasons that it resonates with all of us. We all like to believe that everything we do has a deeper meaning, that every experience is building to a purpose and therefore no time and energy is ever truly wasted.  I like to think that way on a personal level,  but I also think this can be applied to entrepreneurship and product development.

Businesses are products of several environmental inputs:  the entrepreneurs behind them, the industry that they serve, the macro-economy, the trends at the time, customer needs, etc.  I believe many budding entrepreneurs, especially in the MBA communities, spend a lot of time thinking about these inputs and putting them into their business plans.  I think this is smart work to do.   You want to make sure that the market exists and is big enough to make your effort worthwhile.  With that said, there’s a limit to the value of doing this exercise and very few people seem capable or willing to take the next step, which I believe is creating a minimum viable product for early adopters to see and give you feedback on.   There’s a limited amount of planning that can be done in the startup phase, and much of entrepreneurship is based on experience and a ‘hunch’ that there’s some white space where you’re attacking.  5% of your learning will happen in the business planning process, 95% of it will happen when you start building.

In software, this process is called iterative development, or the agile method.  Here’s a quote from the wiki page:

The basic idea behind the agile method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added.

Creating a feedback loop that includes early adopters will allow you test many of the assumptions that you’ve made in your business plan.  It also allows you make changes to your business model based on what you’ve learned.  When we built Crowdstream, we weren’t really sure what was going to resonate with artist managers or with fans.  It took four iterations to get it closer to right and we’re still iterating.  The product that we have today is vastly different from the product that we originally designed, but looking back its easy to connect the dots.


Using Narratives

Everyone loves a good narrative

Having worked in both business development and production,  I feel like I’ve learned a lot about people.  The importance of people in every job function can’t be over stated.  It doesn’t really matter if you’re selling enterprise software, building a product or making a trade,  you need to think about the person on the other side.  People are the consistent thread no matter what desk you’re sitting at.

I had an experience the other day responding to a request for a technical document around a piece of software.  The request was to write out a summary of something technical to an audience that was mostly non-technical, and then to discuss it at a meeting.   As an experiment, instead of writing out a summary, describing the environment that the software lives in, and listing the functional components of the software, I wrote out a narrative.  The narrative was a story about a person who I considered to be a typical user, going through a typical experience needing and using the software.  I named the user John and told a story about him using the software:  how he found it, why he wanted to use it, what he did when he started using it,  how he interacted with it and what brought him back.  It was highly effective and I think everyone appreciated the approach.

There are a few reasons that I think narratives rock:

  1. Narratives are familiar to everyone:  When was life better than when you were getting stories read to you as a kid?  When you start telling a story, your audience naturally falls into a more relaxed state.  Everyone understands stories because they’re relatable.  There’s no need to try to ‘keep up with the technical details’, so there’s very little anxiety about the complicated topic.
  2. They are visual:  People love visuals.   If you don’t have a designer nearby, a narrative is your next-best asset.  Good visuals create memories by eliciting emotional connections.  If your story explains a user and then the use case, everyone has a person in their head walking through a process. It helps complete the picture for the listener.
  3. They force the storyteller to think about use case:  Storytelling can improve your product or idea.  By creating stories to present, the storyteller is forced to think from a user or customer’s perspective.  This sounds overly simplistic, but I found it to be incredibly productive and a creative way to understand the software.
  4. They offer a platform for deeper conversations: To me, this was the most interesting benfit.  After the story ended, all of the followup questions came in the form of questions about the narrative’s main character.  Instead of ‘How does X do Y?’,  the question was “What happens if John…?”  This made the followup creative and productive, and kept everyone thinking through the process using visuals. It was the most productive product overview conversation I’ve had in a long time.
The idea of using narratives isn’t new thinking.  Come to think of it, it’s probably the oldest form of communication that we have.  I bring it up because it’s a resource that I forgot about, and remembering it really helped my process.  If you have to explain anything complicated, consider turning it into a narrative and see if it changes your approach and the response that you get.  I bet that it will.