kevin donaldson

The best definition of a startup I have heard is this:

A startup is a human institution designed to deliver new products and services under conditions of extreme uncertainty.

With the above definition, many groups other than what you might think of with the word startup could qualify.  Its not just Google or Skype.  It could be a new business unit within an existing company or even a department deliverying new products.  It has a lot more to do with how the team operates and thinks about how to solve the problem - remember its a human institution - nothing to do with company size, sector or industry.

With that - take a look at this slide deck which merges ideas from two of my most favorite books - Business Model Generation and The Four Steps to the Epiphany .  The concepts here apply way more broadly than what is typically thought of as a startup.  Its a way of thinking about solving problems.

A startup is as much about mental preparation as it is about the idea.  If you have never done one you can do a lot of wheel spinning all the while burning precious capital and time.  Software can be especially daunting especially if you have either never done it before or you have come from a traditional large company.  If you have an idea for a software application - a web app or possibly a mobile app here are 5 resources that will put you in the right mental frame of mind:

1. Getting Real - The smarter faster easier way to build successful web applications

• A bible for the software startup, written in 2006 by 37 Signals.  You can read it for free online or purchase PDF or paperback..

2. The Entrepreneurs Guide to Customer Development

• Forget traditional product development methods.  They assume you have a market.  The goal of a startup is to find a market.  This e-book is a quick start to understanding new thinking on customer development.  Once you have digested this, you can then migrate up to the original authority on the topic: The 4 Steps to the Ephiphany.

3. The UX Driven Startup

• I was just recently made aware of this presentation but find that it provides a great summary perspective on an often missing link in many software startups - how to think about the user experience, and design.  For consumer apps, the design and user experience is more important that the technical design - especially early on.

The last two are not strictly related to software development - more of what I would refer to as 'business philosophy' books that will complete you mental preparation.

4. Rework

• Another resource from 37 Signals.  A collection of amazing and quick-to-read essays in one consise book.

5. Linchpin

• An amazing book from Seth Godin on making yourself indispensible (which is required if you want your startup to be successful)

3 quick reminders on ideas:

1. Hugh MacLeod wrote a book called Ignore Everybody.  I read it last summer, however today I received my daily gapingvoid email and was reminded of one of the great takeaways from the book:
   

2. There are a million ideas a week.  An idea by itself isn't worth much.  Execution of the idea is where the magic happens.  If you can't execute consider giving ideas away to make them happen. 
3. Stealth-mode is old school.  Forget NDA's, forget patents - share your ideas with people in your target audience to get rapid feedback ... then refer to item #2

Here are the slides from a presentation I gave last night to an MBA class at George Fox University.  I presented what I feel are the 3 imperatives for managing a modern business:

A couple of months ago I was given the opportunity to review some early work on an e-book by Brant Cooper (Market by Numbers) and Patrick Vlaskovits.  It was rough at the time but the idea of simplifying the very meaty 'Four Steps to the Epiphany' by Steve Blank would be a nice thing to add to the available materials in the Lean Startup community.  I had a great conversation with Brant at the time and looked forward to the completion of their work.  At the end of April they officially launched their book "The Entrepreneurs Guide to Customer Development - A Cheat Sheet to The Four Steps to the Epiphany" at the Startup Lessons Learned Conference in San Francisco on April 23!  Last week I received a free copy for review.   Over this past weekend I read through the 73 page book and was very impressed on this nicely written, concise and easily referenced content.  The e-book focuses the Customer Discovery aspect of Customer Development, which is arguably the most important step for startups.

It's also much more than just a summary of The four Steps by bringing in other concepts from thought leaders in the space including Eric Ries, Sean Ellis, Brant Cooper and others.  While you can find all of this information scattered across many articles and blog posts over the past couple of years, it is really nice to have it consolidated in one place in a well organized format.  It is much more of what I would all an MVLP - A minimum viable learning product.  For example - just recently i wanted to introduce the concepts of customer development to a member of my team.  I gave her my copy of  The Four Steps which she is currently wading through, however, from a learning perspective The Four Steps is way more than an MVLP.  This e-book is much closer to that model and much more digestible for those looking to understand the basic and get started.  I also believe it would be a great introduction to managers and practitioners that may not be directly involved in Customer development but still need a good understanding of the concepts. 

While customer development is optimal for use in startups and chaotic environments I would contest that every business should operate as if they were under these conditions.  And while I agree with the authors when they say that these concepts can become more difficult to implement in a pure way the further you are down the path you are in the development of the business,  they can still be very useful in any organization.  Minimally it can serve as a great mental model to help move towards customer centricity.  Take for instance a large mature organization: An internal IT shop could use these concepts on all software projects, and no matter what aspect of a business you are working in you can always get out of the building more and better understand your customers and market.  After all, the market doesn't stand still and its moving faster than ever - why not be ready and on top of your game.   As I heard Eric Ries say in a recent presentation 'Disruption is coming to an industry near you'.  Be prepared with Customer Development.

We have practiced agile in my current startup for 3.5 years we have gotten very good at executing quickly and under conditions of extreme change and uncertainty.  Our product development team is considered an organizational success story of consistency and execution excellence... but is it to a fault? While we have done a great job of shifting with the needs of the market, while still maintaining consistent output and consistent improvement, I can't help but feel that a focus on execution (ie - releasing code) which is deeply ingrained in our culture is often detrimental to an objective of product market fit.

Yes - We talk to potential customers, actual customers, we carry out usability testing, and pre-testing of new features before then go into development when possible, but what got me thinking about this was a comment made last week:  'as we grow with more clients, we need to be more careful about how we iterate into new features to ensure they meet a minimum standard of feature readiness for usability'. This comment essentially implied that iterative development and usability is an either-or choice!   But why?  And then I thought about our culture of execution.  For example - how we measure progress of product development in terms of points/features released.  Could this be closing our minds to other mechanisms of 'release' and clouding the real goal of finding a way to validate a hypothesis with a customer?   What we need is a cultural shift in thinking from a focus on execution to a focus on learning. 

Take for instance the Agile scrum board with its focus on execution.  In scrum, stories (features etc) don't get counted as done until they pass acceptance tests and the code is ready for release. Once the code is released the team is then on to the next batch hoping that this iteration is taking us down the right path and waiting for feedback while we move on to execute on other things. 

Maybe there is a better way... recently I have heard discussions in the lean startup community on how the scrum kanban board could be modified to create a learning focus vs execution focus.  It's the idea of adding another column to the kanban for customer validation with specific limits set on how many items can be sitting in that column.  Working code is no longer the measure of success, but validated learnings about a change are.  This intrigues me.  Limits would not allow the team to take on new work until other items can be validated and cleared from the queue.  It even has the potential to help ensure that certain things don't even get started until there is a valid mechanism on how it could be validated?

Yes - when something like this is proposed in a culture of execution the response will most likely be 'That will slow us down'?  This type of comment is the root of the problem in an execution based culture.  If the focus was on learning one would see that this will likely make you go faster.