Steve Blank consistently writes one of the best blogs.  His installment (at least 2 parts) on the National Science Foundation Innovation Corps is no exception.

Of course the knee-jerk reaction from most people is that government cannot help in such situations without screwing things up… but then you see things like this:

63 scientists and engineers in 21 teams made 2,000 customer calls in 8 weeks, turning laboratory ideas into formidable startups. 19 of the 21 teams are moving forward in commercializing their technology.

That’s a great result from what they set out to tackle.  And of course there are no guarantees that these ideas will work – odds are most of the 19 proceeding will fail. But if the NSF can get scientists thinking about commercializing the tech they produce, the economy (and the US) will benefit as a result.

And keep in mind Steve Blank’s “Secret history of Silicon Valley”:

The Scientists, the NSF and the teaching team were all going to go where no one had before.

Given that Silicon Valley had started with scientists and engineers not MBA’s, I thought this was a bet worth making.

Pretty cool.  But the crazy thing is that they’re going to keep going – doing cohorts of 25 going forward.  Have to applaud this program for trying to get the most out of government R&D dollars – and hopefully spawning some startups in the process.  Just another interesting test case for the “process” of teaching entrepreneurship (and as he put it, applying the scientific method to developing a business).

Yesterday’s post on the Cosmonaut has me thinking about how new products are developed and released into the wild.  We focus so much on startups and processes in the software and virtual world, but Kickstarter has exposed a new process for physical products:

1. Come up with an idea for a product that you think people will want, but you don’t see satisfactorily provided to the market.  (ideas are often for art projects or music albums, not just consumer products like this)
2. Build a prototype and put together a pitch video to sell the idea
3. Do the research to figure out how big a production run you need to do to make the object “affordable” (whatever that means for what you are pitching).
4. Put your kickstarter project page together, including a fundraising goal that supports your minimum requirements.
5. Wait to see how many people and $ show up to support your project.
6. When (if) project funds, get started building the product (or producing the benefits the contributors are entitled to).
7. Ship it.  If it sells well, consider selling more of the product online, knowing that you now have won over an early adopter fan base.

It favors small production runs, prepaid by motivated customers.  The magic is that you don’t put capital at risk until buyers have paid (up front!) for the product.  It is a great way to get pre-commits from a motivated community. And to my way of thinking, this is just a new (and better) process for finding demand when you don’t have the capital to “build it and hope they come.”

If we relate this to the Lean Startup, or specifically to Steve Blank’s incarnation the Lean Launchpad – one of the key tenets is to “get out there and talk to customers”.  Moreover, to find paying customers.  Not just customers who say they will buy it, but customers who will literally write checks to you.

And when they do this – in great dollar amounts or numbers of customers – then you move into production. Kickstarter gives the product team a chance to do this with physical goods in a way that was nearly impossible 10 years ago.  It also allows an innovative team to address niche demand in a way that they previously couldn’t.  In the same way that eBay allowed people to find markets for niche products, so does kickstarter – in one case auctioning used goods, in the other case contributions toward products that don’t yet exist!

This moves physical products into the realm of a process that looks like:

1. Design
2. Sell
3. Build

Which is much more capital efficient than

1. Design
2. Build
3. Sell

As it allows for less waste (building products that no one wants- akin to getting the requirements wrong in software and BPM projects).  And it allows for some feedback loop between design and selling, before moving into the build phase.

It feels like something that could be truly transformative for small business product development.  I have several friends in the business of producing physical objects for sale (furniture, productivity tools, gadgets), and I’m telling all of them they have to try this process and see if it works for their business, and reduces the risk for them.

As a buyer, the other thing that is really fascinating is the exposure to the process, or craft, behind the production of these objects.  The videos and written updates about the procedures are quite educational.  As a process guy, I see it all through the lens of repeatable process with, typically, an irreplaceable human component.  Gratifying craftsmanship.

Steve Blank’s two-part series on the iPhone is definitely “a different perspective”:

The concept of yearly “improvements”, whether styling or incremental technology improvements, every model year gave GM an unbeatable edge in the market. (Henry Ford hated the idea. He had built Ford on economies of scale – the Ford Model T lasted for 19 years.) Smaller car makers could not afford the constant engineering and styling changes they had to make to keep competitive. GM would shut down all their manufacturing plants for a few months and literally rip out the tooling, jigs and dies in every plant and replace them with the equipment needed to make the next year’s model.

The title of the series is “How the iPhone Got Tail Fins”, using GM and Ford as foils for the smart phone businesses competitors.  A fascinating way of understanding the market, and how business processes can affect strategy, or vice versa.

It is just hard to see how this news, courtesy of Steve Blank, could possibly be bad news:

Today, the National Science Foundation (NSF) – the $6.8-billion U.S. government agency that supports research in all the non-medical fields of science and engineering – is changing the startup landscape for scientists and engineers. The NSF has announced the Innovation Corps – a program to take the most promising research projects in American university laboratories and turn them into startups. It will train them with a process that embraces experimentation, learning, and discovery.

The NSF will fund 100 science and engineering research projects every year. Each team accepted into the program will receive $50,000.

I feel sure that some will nay-say.  But Steve Blank has documented on his blog how the government has fostered a startup ecosystem before in his Secret History of Silicon Valley series, and this has some of the same feel to it – but with the added impetus of a better way to wrap scientists and researchers brains around the concepts of startup formation.

As a process guy, I’m really impressed with how much the process of “starting up” has been improved upon in just the last decade – and Steve Blank and Eric Ries and others in the Lean Startup movement are behind much of it (too many contributors to name in one post – because it really is a collection of ideas from many people and companies). I’ll continue to follow along as it informs our own growth as a “startup” consulting firm, but also because there are interesting cross-pollination opportunities with the process improvement work we do.

Congrats to Steve Blank, the NSF, and everyone else who was part of making this I-Corps program come true.

Steve Blank’s process for teaching entrepreneurship – The Lean Launchpad – is a bit like the process for teaching the startup process.  It is a fascinating evolution to observe as it develops; and the results are impressive.

I recommend reading the whole series of posts, but if you are the kind of person that reads the last chapter first, or likes to eat dessert before the entree, then have at it.

So what is this Lean Launchpad class in his words?

Business plans are fine for large companies where there is an existing market, existing product and existing customers, but in a startup all of these elements are unknown and the process of discovering them is filled with rapidly changing assumptions. Experienced entrepreneurs realize that no business plan survives first contact with customers. So our goal was to teach something actually useful in the lives of founders.

Building a product is a critical part of a startup, but just implementing build, measure, learn without a framework to understand customers, channel, pricing, etc. is just another engineering process, not building a business. In the real world a startup is about the search for a business model or more accurately, startups are a temporary organization designed to search for a scalable and repeatable business model. Therefore we developed a class to teach students how to think about all the parts of building a business, not just the product.

Clearly the use of the business model canvas to capture assumptions and iterate over them is a big step forward compared to previous approaches (not that that was the only innovation).  We’ve used the business model canvas at BP3 to explain our business model, and we’ll likely use some of these techniques to tweak our business model in the future.

One of the key learnings:

3.  The process worked for all types of startups – not just web software but from a diverse set of industries – wind turbines, autonomous vehicles and medical devices.

I thought that was pretty telling.  A good process for a startup should work for more than just web software startups.

If you think you’re doing something that is just too damn creative for a process, read Steve Blank’s blog on startups.  The process may not be tightly bound or automated, and doesn’t need to be.  But there *is* a method to the madness and it can be repeated However, the outcome isn’t guaranteed to be successful – it is a startup after all.  Part of me wonders if the BPM community would be willing to accept that idea of following the process but still having an indeterminate outcome… interesting discussion to have!

Since the beginning of the SXSW-interactive conference, I’ve posted a few times about the Lean Startup sessions and hinted that they might apply to BPM.

Heading into the IBM Impact conference, this feels like the right time to talk about the Lean Startup as it relates to BPM – it provides a decent segue to the topic we will speak on at Impact – “Keeping the Business in BPM“.

Let’s Review What the Lean Startup is All About

It turns out, I’ve written about this before.  But I think it is time to return to the subject with a little more perspective.  The premise behind the lean startup is embodied really well by three charts (click on this link, slides 20-22).  I’ve given each idea my own poor rendition here in the blog since I don’t see a good way to embed a single page from a SlideShare presentation.

Known Problem, Known Solution: Waterfall method

First, Waterfall development techniques were designed around situations when we know the problem really well, and we also know the solution well, and simply have to make sure we deliver a quality result.  It should be no surprise to anyone in the BPM space that this does not describe the typical BPM / Process Improvement project.

Known Problem, Unknown Solution: Agile Method

The second slide shows an innovation over the first: that when the problem is known, but solution unknown – a different technique is required to solve the problem:  Agile development. There have been many proponents of an agile approach to software development, and it is arguably the most accepted methodology among software engineers.  This does not mean, however, that it is always practiced, or practiced well, nor has it infiltrated all IT projects.

Lean Startup: Unknown Problem, Unknown Solution

The third slide shows yet another innovation: when the problem is also unknown, the solution is unknown.  At this point, we can’t rely on just documenting the requirements or interviewing the known user base.  We have to apply what Steve Blank coined as “Customer Development” – getting out of the building and talking about our problem hypotheses with customers.  When we get our hypothetical problems and hypothetical solutions in front of customers and discover we’ve “missed” the market, we “Pivot” – that is, take the lessons learned, and adapt what we’re doing to find an addressable market we can actually build a business around.  Essentially, the lean startup keeps iterating and pivoting until it finds a business that it can scale (or until it runs out of money).  Once it finds something to scale, the problem is no longer one of “searching” for a business model and solutions, but one of scaling an operation.

The coupling of the Customer Development process with the Agile Development process has been coined the “Lean Startup” by Eric Ries and others.  Why do we call the problem “unknown”? Perhaps you think of course we know what problem we’re attacking – the startup company was formed to solve this particular problem.  That sounds good – but actually startups only THINK they know what their business model will be.  Google thought their model was search.  But it was really targeted advertising delivery, based on Search and alongside search.  Small startups pivot often, but we’ve also seen large companies pivot – as IBM did when it moved to really emphasize its services business.

How is BPM Like the Lean Startup?  “Problem: Unknown”

Some readers should already be seeing a connection between the Lean Startup and BPM.  But it helps to really spell it out.  First, I propose that when you start a BPM project, you only have a hypothesis about your problem and solution.  This is what we mean when we say the problem is “unknown” – that we have a hypothesis but it isn’t proven yet.

How do we know that BPM suffers from this “unknown” Problem situation?

Because the biggest risk to budget, or even success, of BPM projects, is getting the requirements wrong.  As I often tell our team: “No, you’re not going to get good requirements up front for this project. And if you do, they’re probably wrong.” We have to approach projects with an open mind toward how requirements will evolve.

Already, most BPM practitioners approach the solution as an “unknown” or “hypothesized” solution.  This is why, for example, successful BPM projects typically have an Agile, or at the least iterative, approach to BPM development – it allows opportunities for course correction with the Business, getting closer to the “right” solution over the course of several iterations.

BPM Takeaways from the Lean Startup

But, the other side of the coin is that we BPM practitioners need to adopt some of the methods of the Lean Startup and Customer Development:

1. We need to “get outside the building”. For the IT folks developing BPM solutions, this means going outside the IT labs and seeing how the “Business” really operates.  Talk to them.  Observe them.  Read between the lines.  Get their feedback on prototypes and early releases.
2. We need to employ more A/B testing in our solutions. Don’t assume we’ve designed the right improvement to the process – prove it!  A/B testing is de riguer in software circles, but not inside IT shops, and not in process improvement methodology.  But it should be.  I’ve only seen one BPM endeavor really embrace A/B testing – and it was a great success.
3. The unit of progress is learning. This is a core principle of the Lean Startup.  While we’re searching for the right problem to solve, and the right approach to address it, learning is what we want. An A/B test that shows we didn’t move the needle as we wanted to is a success if we have learned a better path forward or avoided a costly dead-end.
4. Shift to Value-Based Delivery over Plan-Based.This means that we have to re-prioritize work throughout the project – to always keep the Delivery team focused on the highest value work.  The plan is your hypothetical plan.  Don’t stick to it when the facts dictate otherwise.
5. Get the Business and the Technical Team working together. Seriously.  Put them in the same space. Or the same room.  Make them part of the same team.  Make it the dream team.  Because when you get the leadership and team right, everything else gets easier.

There is more to it than just this… But if we can just pick up these four things for our BPM projects, we’ll make dramatic progress on improving the process of BPM. It takes leadership to drive these behaviors – but I hope that leadership just needs a little bit of encouragement through education and familiarity with the concepts behind the Lean Startup.

I’ll see many of you at Impact – in our session, I’ll touch on the whys and hows for a business-driven technical team.  And if you read this blog, you’ll have some of the underpinnings behind my part of the talk.  Of course, Lance and Reid have a few interesting points to make too!  Wednesday, April 13, 3:15PM to 4:30PM, In the Venetian – Murano 3205 room: “Wells Fargo – Keeping the ‘Business’ in BPM”

Steve Blank was the star speaker among an incredibly strong cast of speakers at the Lean Startup sessions at SXSW-interactive.  The room was packed, and SXSW volunteers were keeping more people out in the halls to obey fire codes.  There would have been people sitting on stairs and on the floor if allowed.  I guess there were a few of those, but mostly just near the power outlets (people who didn’t have iPads to take notes on).

Steve speaks as well (or better) than he writes.  His talk was engaging and energizing.  He started his talk (and a blog post I’ll quote here, based on the same topic) discussing a quick history of the four waves of startup investing:

• The Golden Age (1970 – 1995): Build a growing business with a consistently profitable track record (after at least 5 quarters,) and go public when it’s time.
• Dot.com Bubble (1995-2000): “Anything goes” as public markets clamor for ideas, vague promises of future growth, and IPOs happen absent regard for history or profitability.
• Lean Startups/Back to Basics (2000-2010): No IPO’s, limited VC cash, lack of confidence and funding fuels “lean startup” era with limited M&A and even less IPO activity.
• The New Bubble: (2011 – 2014): Here we go again….

Not everyone agrees that there is a bubble.  Of course, in order to disarm the “is it a bubble or is it not” discussion, he simply says “if you believe it IS a bubble, then the question is, are the rules different in a bubble than they are otherwise?  Are the rules different now, than they were for the previous ten years?”

It is hard to argue that the rules aren’t different.  Or at least that some tactics that would have been counter-productive or futile before, are now quite effective and productive.

The basic argument is that from 2001 to 2010, the Lean Startup was the way to go – conserving capital, focusing on learning and iterating, and finding a business model that could scale.  As he put it:

Startups began to recognize that they weren’t merely a smaller version of a large company. Rather they understood that a startup is a temporary organization designed to search for a repeatable and scalable business model. This meant that startups needed their own tools, techniques and methodologies distinct from those used in large companies. The concepts of Minimum Viable Product and the Pivot entered the lexicon along with Customer Discovery and Validation.

So far so good.  But what has changed in 2011, and going forward toward 2014?

1. Breathtaking scale.  The addressable market for startups is vastly bigger than it once was.  And so is the ability for startups to serve that scale (via Amazon web services, for example). Mark Suster commented on this in his SXSW recap.
2. New Exits.  There are simply better options for startups to exit now, than there have been over the last 10 years.  IPOs are back on the table.  Acquisitions are at higher valuations.  And the companies that are IPO’ing will have real profits and revenue, and massive customer #’s.
3. Better tools are available – AWS, S3, Google App Engine, Rackspace, etc.  These scaling tools weren’t there 10 years ago.  Moreover, developer productivity is up with new tools like Ruby, Rails, etc.

It seems that the key change Steve is advocating for startups is visibility.  That previously, press exposure might have hurt you by locking you into the wrong path, but going forward, press would help you by expanding your user base, and increasing your visibility for potential acquirers.

But of course, all this advice only applies if you believe there is a new Internet bubble.

There were some great quotes in the talk.  My favorite:  “There are no 10 year startups. There are only 2 year startups attached to 8 year failures.”

Steve pulls no punches, but he does deliver his critiques with a smile and sense of humor.

Slideshow, embedded below, also tells the story quite well:

 
There’s also a great Q&A with Steve Blank on GigaOm – in which he discusses how the total available market has exploded in size, and how he believes a great CEO with a great product could have come out of SXSW-interactive highly visible and talked about. In other words, he still sees SXSW as a place where you could launch.

I just read one of Steve Blank’s posts and I just wanted to share my impressions here. Because the internal debate Steve seems to be sharing with us on his blog is not unlike the debate that goes on in BPM circles all the time.  Here’s my comment in its entirety:

Steve, on the one hand, this post is depressing. You seem to be saying that entrepreneurs are born rather than made. That in some sense, this endeavor to teach more people about entrepreneurship is hopeless.

On the other hand, you pointed out not everyone can use these tools equally well. Well good! If they could, what point in striving against all the other people starting businesses if we’re all automatons executing the master plan.

The point is that you can, with the right tools, raise the game of everyone who uses them. With the right education and experience, you can elevate their internal game and process. You can give everyone a tennis racquet, and they won’t all be equally good, even with the same equipment. But you can teach EVERYONE to be better at tennis. I can’t believe you wouldn’t think the same is true for entrepreneurship, management, running a business.
I’m also disheartened to see people referring to science as if it isn’t creative. It is. If it wasn’t, we’d just let the computers do the science and R&D wouldn’t we? The scientific method and the “Pivot” don’t sound terribly different to me.

The Word processor doesn’t make someone an artist- but it has made people who write more productive – allowing, no doubt, more people to get into writing as a side-career rather than starving while they pursue their craft.

Regarding that practice: recall that it has to be practice with a purpose (the learning that goes with the practice, the purposeful working on weaknesses and leveraging strengths). Giving entrepreneurs a better framework and tools gives them a better shot at practice with purpose.

And having said all of that, I find it encouraging that human variance will still mean that some will succeed beyond others. Because individualism still matters too. That sounds like capitalism to me.

Given how many successful businesses there are in the world, perhaps we think this entrepreneur thing is a little bit more rare than it really is.

I think we too easily discount the creativity that everyone doing work exhibits.  We also too easily give up on the idea that other people can improve.  Almost everyone I’ve ever talked to thinks they can improve themselves.  I feel sorry for the folks I talk to who *don’t* seem to have that belief. What Steve Blank is teaching in his classes and through his blog is an improvement over trial-and-error. But, the best entrepreneurs will take great advantage from his concepts and teaching, and the worst entrepreneurs simply won’t.  It will be that way with any improvement tools or teachings. Is it any different in BPM?

The Lean Startup is a phenomenon.  Day 2 proved it.  Day 2 was not a typical SXSW experience. Instead of scrambling all over downtown Austin to get to sessions, I stayed in one place all day at the lovely AT&T Center.  Eric Ries (@ericries) acted as emcee for the all-day event, which was literally packed wall-to-wall with people and content all day long.

I took copious notes throughout the day.  This day’s sessions were the highlight for me.  The concepts in lean startups and minimum viable product are so relevant for BPM, and not as well understood by our BPM community as you might think. After all, the Lean Startup is focused on areas where the problem is unknown or uncertain, and the solution is also unknown.  In BPM, we face a similar problem – it might be more accurate to say that the problems are “estimated” and the solution is “estimated” – but the point is, we don’t know for sure that we’re solving the right problem before we start the BPM journey, and we don’t know for sure that each solution we iterate is the right solution.  It takes iterations of customer discovery and agile development to get us to a better hypothesis about the problem and solution.  If this sounds like crazy talk, bear with me and read blog posts I’ll put up over the next few days that dig into this further.

Overall the sessions violated one aspect of the spirit of SXSW – there were very few breaks (I counted 2, and one was 30 minutes for lunch), no time for hallway conversation, and no breaks to get out of your middle row seat so that you could have such a hallway conversation.  All of these fantastic entrepreneurs in one space, one room, and we could hardly talk, except via the backchannel of twitter and the like. I think it only worked at SXSW because the sessions were at the AT&T Conference Center, far removed from the center of gravity for SXSW, the Austin Convention Center.

The content was first rate, and there’s too much for one blog post to cover!  But they could have split some of the sessions into two rooms to really make the feel more like SXSW.  It would have forced choices – you can’t go to everything- but the choices would have been good choices, and twitter and blogs allow us to follow content in another session if we’re motivated to. And it would have allowed the schedule to BREATHE a little bit.  Trust me, it needed it.  Finally, it would have allowed for the people who couldn’t get into the sessions in the afternoon to actually participate or watch at least a relevant session, if not the one they were hoping for.  I felt that there was a lot of value pent up in the entrepreneurs in the room, that wasn’t unlocked because there just wasn’t any time at all for the sidebar conversations.

Eric “Pivot” Ries was the emcee, but we had significant appearances and contribution from Dave “Nice to #$@!ing meet you!” McClure , Steve “Epiphany” Blank, and many other entrepreneurs.  My favorite talk, and the one that I was most looking forward to, was Steve Blank’s discussion of new rules for the new bubble.  For this session, even more than the others, it was standing room only, with people sitting on the floors and standing in the hall to listen in.

I had the good fortune of meeting up with fellow Austin entrepreneurs while I was there-  Jeff Chambers, and Ed Roman.  I also spent most of the day sitting with Elliot Loh (@elliotloh) visiting from SF.

Later I got to introduce a couple of my friends from out of town to Garridos, a great modern Mexican restaurant downtown.  We also checked out the Frog Design SXSW Opening party, which, as usual, involved some crazy technical and interactive features, as well as massive lines to get in.

Day 2 was an incredibly long day, with so many notes I knew I couldn’t hope to get my blog up-to-date by the time I finished the day.

The main takeaways:

1. The Lean Startup movement is grounded in real empirical data, real case studies, and real results.  It is no longer an “interesting idea” and seems to be on its way to being accepted as the “best way” to approach starting up your company.
2. Entrpreneurs, investors, and academics from the Bay Area believe there is a sort of “bubble” in investing.  On the other hand, they also believe that the companies likely to go public now are companies that have real scale and make real money.
3. There’s an incredible interest among entrepreneurs to improve their game – especially the ones that are building their companies with minimal or no outside investment.
4. SXSW-interactive has the power to draw an amazing group of people to one spot, to even one room, in Austin, TX.

If they had added an after-party on-site, or a good strong networking break, this would have been the key place to be on Saturday.  As it was, it was the key place to be but no one else would know you were there, and you’d have to track down your like-minded entrepreneurs later in the conference (good luck finding them!).

Interesting blog from Austin’s own Ash Maurya “The Fallacy of Customer Development“, which is really an essay to explain that if you’re developing a web application, rather than enterprise software, you need to apply a different approach to customer development to really get the valid feedback you need.

It’s an interesting adaptation of the customer development process outlined by Steve Blank in “Four Steps to the Epiphany” (I’m partly partial to Steve Blank because several of my friends went to work for epiphany).

But I also find it interesting to follow the development of processes for startups, for customer development, for the lean startup.  Following Steve Blank, Eric Ries, Ash Maurya, and Jason Cohen gets you pretty far along the path to understanding this school of thought.

Steve Blank writes about the “enterpreneurial singularity“, a result of a combination of factors that make it easier than ever to start up a new company – combined with a set of factors that reduce the opportunity cost of doing so (the implied risk is less than it has been in a long time).

The Entrepreneurial Singularity
The barriers to entrepreneurship are not just being removed. In each case they’re being replaced by innovations that are speeding up each step, some by a factor of ten. For example, Internet commerce startups the time needed to get the first product to market has been cut by a factor of ten, the dollars needed to get the first product to market cut by a factor of ten, the number of sources of initial capital for entrepreneurs has increased by a factor of ten, etc.

And while innovation is moving at Internet speed, this won’t be limited to just internet commerce startups. It will spread to the enterprise and ultimately every other business segment.

When It’s Darkest Men See the Stars
The economic downturn in the United States has had an unexpected consequence for startups – it has created more of them. Young and old, innovators who are unemployed or underemployed now face less risk in starting a company.  They have a lot less to lose and a lot more to gain.

This is partly why I’ve remained (perhaps overly) optimistic throughout the recession.  I just believe the seeds are being planted for a sound recovery, and perhaps a more diverse future economic base.  Companies that survive the recession will emerge with new skills, customers, products, and survival skills that will help immensely as the economy grows.

Steve Blank’s posts on the Business Model/Customer Development/Lean Startup stack have been really compelling reading, and I believe are zeroing in on what may be a repeatable process for startups.  It doesn’t mean the process always yields a successful startup – but using the tools and processes outlined, combined with good judgment and great talent appears to give a startup a much better chance of succeeding with the resources at their disposal.

One of his more recent posts focuses on the Business Model Design.  This is a key tenet of his process for startups: that the FIRST job is to find a scalable business model.  Only when this scalable model is found do you focus on actually scaling the business itself.  But how to design and describe the business model was one of those “black boxes” that most entrepreneurs weren’t really sure how to execute.  Steve points to work by Alexander Osterwalder and Yves Pigneur, who have published the definitive work on the subject, “Business Model Generation”.  Steve has, in the last year, started to use their Business Model canvas as not just a static tool, but actually as a launchpad for testing hypotheses and keeping a scorecard for tracking iterations and pivots:

In the last year I found that the Osterwalder Business Model canvas could be used for something much more than a static planning tool.  I realized that it was the launch-pad for setting up the hypotheses to test, and a scorecard for visually tracking iterations and Pivots during Customer Discovery and Validation.

Meanwhile on the other side of the world Alexander Osterwalder was coming to the same conclusion: tying the two processes together would create a “strategy stack for entrepreneurship.”

I find the idea of a process for generating a business model to be compelling.

Steve Blank’s excellent blog includes this post:

Strategy is Not a To Do List, It Drives a To Do List
It took me awhile, but I began to realize that the strategic part of my job was two-fold. First, (in today’s jargon) we were still searching for a scalable and repeatable business model. My job was to test our hypotheses about who were potential customers, what problems they had and what their needs were. Second, when we found these customers, marketing’s job was to put together the tactical marketing programs (ads, pr, tradeshows, white papers, data sheets) to drive end user demand into our direct sales channel and to educate our channel about how to sell our product.

Once I understood the strategy, the To Do list became clear. It allowed me to prioritize what I did, when I did it and instantly understand what would be mutually exclusive.

(My emphasis added to the last paragraph)

Every so often, a conversation builds to critical mass and demands an in-person meet-up.  Eric Ries pulled this show together, and I have to say there is some great video, and there were some great presentations to browse to get to understand better what you can do with a lean-startup approach.

Steve Blank has one of the best overviews with links to all the important content.  And here’s a link to the stream of his talk.  You can find almost all of the presentations on slideshare with the sllconf tag.

Maybe I relate to this conference effort because we put on the bpmCamp unconference earlier this year.  Mainly, I applaud the effort to build momentum and credibility around some really great frameworks.

Steve Blank’s blog has a series of posts regarding the entrepreneurship courses he and his colleagues are teaching at Stanford and Berkeley.  The thing that jumped out at me is that it sure reads like there is a process for teaching entrepreneurship.

Maybe that shouldn’t be surprising.  But it was already eye-opening for me to read the process-oriented approach Steve advocates for developing your business model (aka “Customer Development” , good read on wikipedia by the way), and a process for product development that is highly complementary to this (Lean Startup, advocated by Eric Ries among others).  But it looks like Steve is cracking the code for how to teach entrepreneurship.  Of course, proof will be how well the entrepreneurs who take his classes perform relative to peers who do not attend these classes, and how many other entrepreneurs adopt the techniques Steve is advocating because they’ve heard about them from his students or writings.

Til then, we can apply our own subjective judgment to assess.  So far so good.

Man. Steve Blank writes some great stuff.  Makes me wish I had gone to epiphany back in the 90′s!  He explains that if you’re going to go work for someone, make sure they have big plans, plans to grow the enterprise – because that growth is what you will benefit as a member of the team.

I thought his IMVU example was pretty interesting.  He mentions Will Harvey and Eric Ries (of Lean Startup fame) as being cofounders who wanted to swing for the fences and turned down buyout offers.  So, being me, I click on the link for Will Harvey – and I see he is at “Finale | Fireworks” along with Chris Hondl.  What a blast from the past.  Will was the TA of a Motorola 68040 assembly language class when I was in college (Stanford CS 110 if I recall) and Chris was the star student in the class.  We had a “robot simulation” game where we programmed the strategy for a robot to interact in a maze.  Mine was one of the four finalists, but Chris’ was a class above the rest in terms of the elegance of design and economy of action. Chris went to work with Will at Sandcastle, and most of us in class were fairly in awe of Will for his chops as the writer of music software for the Mac.

There are times when you realize it is a small world.

At bp3, we’re building a business process company, just like the tag line says, making no little plans.

What a great post by Steve Blank, yet again, as he reveals a classic cautionary tale from start-up land (“The Elves Leave Middle Earth – Sodas Are No Longer Free”).

It’s about the Sodas no longer being free.  Seriously.  Coke. Diet Coke.  Mountain Dew.  No longer free.  Free drinks are part of start-up culture and lore, and it is just one of the little perks that founders do for their companies when they themselves are interested in free sodas too.

Shouldn’t matter, right? But it does:

But the damage had been done. The most talented and senior engineers looked up from their desks and noticed the company was no longer the one they loved. It had changed. And not in a way they were happy with.

The best engineers quietly put the word out that they were available, and in less than month the best and the brightest began to drift away.

Worse, as he sat there in the board meeting as the free drinks were getting canned, he was amazed that none of the experienced VC’s in the room objected, or pointed out the folly of this change in policy – from free drinks to paying 50 cents.

Steve was amazed that they didn’t speak up.  But I’m not.  Its like Marvin Haggler once said: “It’s hard to get up and do roadwork when you’re wearing silk pajamas.”  The VCs have forgotten why free drinks matter to engineers.  They’ve forgotten what “road work” is like.  Its surprising that Steve Blank still remembers it so clearly (perhaps the academic/historian part of him hangs on to these memories).

As Steve recalls it:

Then the new CFO got up to give her presentation – all kind of expected; Sarbanes Oxley compliance, a new accounting system, beef up IT and security, Section 409A (valuation) compliance, etc. Then she dropped the other shoe.

“Do you know how much our company is spending on free sodas and snacks?”  And to answer her own question she presented the spreadsheet totaling it all up.

There were some experienced VC’s in the room and I was waiting for them to “educate” her about startup culture. But my jaw dropped when the board agreed that the “free stuff” had to go.

I sure hope Steve spoke up and let them know what a mistake they were embarking on.  I know he wasn’t on the board, he was a guest – but all too often I’ve seen bad outcomes come to pass because no one felt comfortable or felt it was their place to speak up for what they thought was right…

I lived through one of these transitions as well, but for our firm, it really was the beginning of the end – not just a sign for people to look around, but a sign that the management of the firm had dramatically changed their priorities to reflect a new, tougher, economic situation, and the layoffs that were about to come.

I’m tired of waiting. I think I’ve been spoiled by the pace of Web 2.0 and I’m no longer patient for each major release of enterprise software.

In a world where we can receive application updates to SaaS applications daily, weekly, quarterly, I’m tired of waiting for enterprise software to release major upgrades every few years.  In particular, BPM vendors, of all enterprise software companies, should know that continuous improvement is a better method than the big-bang release.  They should be embracing incremental improvement techniques, just as their customers should when deploying BPM solutions.  Why do they talk the talk and fail to walk the walk?

Every BPM vendor (every software vendor!) should read Steve Blank’s Manifesto for Customer Development. Steve Blank and Eric Ries writings should be mandatory for software developers in the BPM business.  Heck, their articles should be mandatory reading for people deploying BPM software as well.  The traditional “product development” model consists of four phases:

1. Concept / Business Plan
2. Product Development
3. Alpha/Beta Test
4. Launch / 1st Ship

And Steve Blank rips the heart out of this process:

The first hint lies in its name; this is a product development model, not a marketing model, not a sales hiring model, not a customer acquisition model, not even a financing model (and we’ll also find that in most cases it’s even a poor model to use to develop a product.) Yet startup companies have traditionally used this model to manage and pace not only engineering but also non-engineering activities.

So.  Off to a good start.  So what are the problems?

1. Focusing on a finished product instead of minimum feature set.  Lots of resources are going to be wasted on features that won’t matter to customers.  Those resources won’t then be available to invest on features that DO matter to customers.  Guess what?  Software vendors have finite resources.   These prioritization decisions matter.
2. Founders or Executives hand-off responsibility for validating the vision.  Marketing and Product Management now own that, and Sales.  The founders and executives aren’t hearing directly from customers which features are buying criteria.  Founders and top execs need to hear customer feedback in order to know when the ship needs to be righted.
3. Engineering becomes so focused on their ship date execution plan, they become immune to outside input, or changing the plan, except to move the ship date further out, or cut features.

In another article, this time on GigaOm, Mike Speiser argues for the power of Continuous Improvement.  Well, he’s preaching to the choir with me, because as a BPM practitioner I’ve been advocating continuous improvement for most of a decade.  Mike argues that often the reason people (and businesses) languish at a mediocre level of performance is simple:  they lack a good feedback loop.  Without timely feedback, they can’t tell if their actions will produce exceptional, average, or mediocre results.  The learning cycle is too long to take hold.

A fantastic example of what can go wrong in a big organization:

Let’s say you’re a mid-level executive — a GM or product manager of some sort. More than likely, you’re measured by how well you interact with and present to your manager and senior executives. Consequently, you optimize to managing the bureaucracy (your boss in particular) rather than delivering the right product or service to customers. And so does your boss, and her boss, and so on and so on. Here the only thing that you’re practicing and perfecting are your brown-nosing skills. How can you expect to learn in an organization with that type of feedback and incentive system? How can such an organization, by extension, possibly produce excellence?

The most telling quote of all:

The organizations that produce excellence are those that continuously improve. The more granular and frequent the improvements, the better.

Its worth reading that one twice.  Three times.  Now.  If you’re a BPM vendor, and you have an enterprise version of your product, ask yourself if this statement applies to you, your team, your product, your organization.  You may be saying to me right now- but we’re on version 5, version 6, 7, version 10, of our BPMS – so clearly we believe the gospel of continuous improvement.  But I say to you, how long was the development effort that led to this latest version?  Why was it more than 3 months?  Why is there a “major version” at all rather than a series of incremental improvements that migrate customers from old to new?

Many of the BPMS vendors are now providing SaaS or ASP oriented BPM solutions – at least for modeling and collaboration, if not for execution.  These solutions seem to get revisioned on a frequent and substantial basis, much like the majority of web applications and “Web 2.0″ out there.  I would now like to challenge the assumption (presumption) that Enterprise software can not be similarly improved.

What’s wrong with the traditional product development model for BPMS vendors (my observations):

1. There are large sets of features that languish without improvement for many years.  A mediocre feature was introduced in 2005, it was never revisited, except, perhaps once to fix a bug in 2006.  This “feature” might be something really important to customers:  reporting, versioning, integration with salesforce, etc.  But for whatever reason it never rises to the level of interesting for Product Management, or it gets cut in the interest of making the almighty ship date.
2. There are large swaths of potential features that never get addressed, because the product development team imagines it knows what is going to sell when the shiny new release is finally released.  So, that PDF export you wish you had in product continues to be something professional services had to provide.  That import from Visio the customer wants isn’t available in your otherwise superior product, and the customer goes with another product that does this out of the box.
3. Low priority defects never get fixed.  Why fix them, when the “new release” is coming.  Wait for the new release, then consider fixing these minor things on the new release.  The problem is, the new release will introduce its own set of important issues to fix, it will take time to confirm the minor issues are still issues on the major release, and by the time those minor issues are back on the table again, the answer from engineering will be: this is too low-priority as you’re on the old release – we have a new release coming that will be the one to fix this on.  So, you spend more time waiting for the Next New Thing than you do actually treating it like the tip of your product line.

If your major versions take more than 1 year to ship, you’re doing something wrong.  And that may be generous.  How do I know that?  Apple ships new versions of an operating system every 12-18 months.  That’s a much more daunting task than a new BPMS.  Much larger installed base.  So why does it work?

1. You have to make the investment in automated update mechanisms that work. Think Windows Update, Mac Update, etc.  These programs work.  The changes they propagate have to be *contained* and backward compatible.  But they work. It puts constraints on the engineering team – but they are *good* constraints that these teams ought to operate under anyway.
2. You have to compartmentalize your updates into components or units that can be upgraded without breaking everything else.  Think Apple replacing their legacy development framework with Cocoa – something that they did gradually over the last 10 years, piece by piece.
3. Independent components imply that you have to have good API’s.  If you don’t have API’s defined between the internals of your product that you feel comfortable documenting and publishing internally and to partners, then you should develop and implement such API’s as part of every revision to your product.  API’s provide the lubrication that allows for change in your product without putting unaffected parts of the product at risk.
4. You have to respect data formats.  The data is sacred and hast to be protected.  See #3 – without APIs protecting your data, you won’t be able to change the schema without breaking upstream services.  And you won’t be able to change upstream services without breaking your data.
5. You have to believe in the evolutionary/incremental over the revolutionary.  If developers think they can depart from the past without respecting it, you will get incompatible software and unhappy customers.
6. You have to allow for individual accountability for product.  If people don’t “own” something, they won’t have the appropriate baked-in incentives for improving it. My favorite question to find out if a company is serious about a feature set, is to ask who owns it – who’s your lead developer for this part of the product?  What are their other responsibilities?  How long have they owned it?  Can I talk to them about what they’re working on now and why?  I want to understand their thought process.

I see enterprise BPM vendors talking the talk about continuous improvement.  But I don’t see them walking the walk in their enterprise software offerings.

There are times when we must ditch the plan and we often talk about these moments when a good leader has changed course to effect a better outcome.  These tend to be fascinating decisions to study because we wonder, how did this person know that now was the time to change course, and not earlier, or later?  What was the information that led them to this decision?

But there’s another situation to look at: when the plan (or process!) is clearly defined, but we fail to follow it.  In reading Coffee with Startups (by Steve Blank) I couldn’t help but think about the fact that Steve has outlined a clear process (Customer Development), some clear differentiators to apply to that process (what type of market – an “Existing Market” in this case), and published myriad articles about the subject.   He describes coffee with four startups that claim to follow the Customer Development process but communicate clearly in the first few minutes that they have not followed it or completely missed the point.

This can happen with processes within your own organization – no doubt you’ve observed cases of this yourself.  But you can’t afford to have the captain of the ship ignoring the process that is understood to be the right one to follow.  If they pick a plan or a process, they need to be able to implement the plan – both in order to make it work, but also to be sure that if you decide it doesn’t work, you’ve actually given it a chance by trying it in the first place.

The entrepreneur may decide that Customer Development isn’t the right process for their company to follow… But if it isn’t, then the entrepreneur should follow the one they believe in, and not play lip service to one that they don’t. The same advice follows for process – if you define the right process – follow through on it.  Implement it, get your organization to execute it well.  Only then can you change it from an informed baseline opinion.

No, this isn’t a political posting!

I just read Steve Blank’s blog on Faith-Based versus Fact-Based Decision Making, and it resonated really well with my experiences at prior startups.  As he points out, starting the company is an article of faith.  The first company I worked for was started by 5 Stanford undergrads, most of whom dropped out of school to start the company.  That is certainly an act of faith.  However, as the company grew, there was more and more data available with which to make good decisions. Steve Blank’s post focuses primarily on the product development, customer development, and marketing aspects.  But it is true of every facet of your business.  And the transition from faith to fact is important.  Not doing it can lead to some pretty bad decision making down the line.  At the company referenced above, 10 years after its founding, veterans often referred back to faith-based decisions in the past as articles of proof that the right way to make a decision was based on faith rather than based on facts.  “If we had relied on your facts, we never would have <insert action here, that gleaned millions of dollars for the company, or brought a key person into the organization>”.

Well, it is often hard to counteract this sort of discussion.  But let’s take another aspect that most people can relate to:  hiring.  The first time you hire someone for your startup, it is an act of faith.  Oh sure, you have the resume, you check references.  You interview. You interview again.  You have lunch, dinner.  You meet for coffee.  You spend a lot of time with that person.  And it is still an article of faith when you hire them.  Why?  Because the role you’re hiring for isn’t well-defined (almost by definition in a startup).  Because you don’t have enough other interviewers to compile feedback from.  Because you don’t have enough candidates who are willing to work for peanuts and equity (or even for cash for a risky proposition).

It turns out, at a larger company, every time you open a new position (role), you run into this problem again.  You don’t know exactly what the job description is. You don’t have anyone else to compare the candidates to in terms of “this guy is good at that job”.  You don’t even have consensus on what it means to *be* good at the job.

At a previous employer we needed to hire someone to run our recruiting operation.  The first person our HR director brought in, came highly recommended by an executive at another local company. Our HR director was confident they would pass the executive interviews with flying colors. But the candidate bombed across the board.  I told the HR director we’d likely have to interview 10 candidates before we would figure out what we really wanted out of the job, and if we were lucky, one of those first 10 would fit the bill – but if not we’d have to be prepared to interview and additional 5-10 people at least.  She was mortified at the idea of doing that kind of work for “just hiring a recruiter”.  But we wanted someone who would really make the recruiting process run smoothly and help us source good candidates.  Sure enough, we churned through 10 candidates… and then made our compromise, by realizing that we needed a different style of recruiting for engineering than we did for our professional services team.  Our engineering hires were heavily dependent on the local networking capability of the recruiter – we needed someone with deep Austin connections who could get people who weren’t looking for a job to pick up the phone, and help us make the sale.  But for professional services, we needed someone who had a process for finding people all over the country, and screening them before they got to us so that we didn’t waste too many cycles interviewing people who were obviously not a fit.  (Our professional services group had a regional staffing model)

But once you get big (as my first employer did) and you’re hiring for a well-understood role, you can establish really interesting hiring machinery.  Everyone goes through 4-6 interviews with specific goals.  You track statistics on each interviewer, and on the folks that you hire, to correlate interviewers positively or negatively with good hires (note: you have to have a review system for this to work).  You correlate job performance with GPA, previous job titles, industries, etc.

We were doing a lot of hiring of people from college.  The data said that people with above a certain GPA, who also passed our rigorous interviewing process, generally did quite well.  There wasn’t a lot of additional correlation of higher GPA to higher performance, surprisingly enough (some, but not much).  However, the data also said that we rejected something like 99% of the folks with less than that cut-off GPA who were granted a first round interview… And worse, most of those we hired with less than that GPA didn’t perform as well as those with a higher GPA.  My read on the data was simply that our GPA cutoff reflected more about commitment than smarts.  After all, the people who passed our interview process were smart. So why would they get a bad GPA?  Mostly, they weren’t committed during college.  I’ve known people like this all my life – and most of them eventually find what moves them, get committed, and go forward with much success from that point onward (sometimes in highschool, sometimes in college, sometimes graduate school or the first or second job).  But there is no way to predict what will trigger their inner mojo.  And there is no reason to assume that your company is the secret ingredient that will unlock their motivation!   Our recruiters, however, had it as an article of faith that some of the most outstanding employees had crummy GPAs (or even dropped out as the founders had!).  They were arguing that we should continue to make these leaps of faith.  But outside of the founders, every other successful anecdote with the low GPA was someone who had previous industry experience where they had demonstrated excellence.  In other words, once someone has had a real job, GPA is pretty irrelevant as a predictor of performance, compared to data from their previous work history.  We did NOT have a compelling case based on the facts, for college hires with low GPAs achieving success at our firm.

I think the key lesson is:  when you don’t have enough data, you still have to make a decision, make the best decision you can.  But when you have enough data, let that data inform your decision-making.  Don’t confuse good fortune with a good process.