The highlight (for me) of last year’s SXSW-interactive conference was the Lean Startup SXSW – a whole day of planned content, mainly in one room (in the AT&T executive center) focused on the idea of “the lean startup”.  Eric Ries and team did a phenomenal job bringing together a set of topics and speakers that you just normally wouldn’t get exposure to in a single day.

Leveraging the success of that forum, SXSW has created the Startup Village this year.  The 4th floor of the Hilton will be converted to startup mecca.  I thought the “Lean Startup SXSW” track might have gone away in favor of this modified (and bigger billing) approach.  Apparently not so.  Today SXSW.com announces that they’re bringing Lean Startup SXSW back – and some of the chief instigators are involved again – Eric Ries, Dave McClure, Steve Blank, 500 Startups, et al:

The Lean Startup SXSW will take place on Saturday, March 10th from 9:30am – 6:00pm at the Downtown Hilton (across from the Convention Center), and the most up-to-date agenda can be found here.

So, more central location, same Saturday location in the schedule (good call).  The agenda already has enough speakers identified for me to plan my Saturday schedule.

Once again, good evidence of how SXSW adapts and co-opts good ideas from the outside.  Congrats to the organizers, I’m looking forward to it.

Fred Wilson (and others) have been advocating for immigration reform – and in particular for doing a better job of hanging onto talented people who want to start companies in the US (thus, the startup visa movement).

Vivek Wadwha, Eric Ries, and now Mike Bloomberg have all weighed-in in favor of the Startup Visa.  Bloomberg has also advocated allowing any foreign nationals to immediately get a green card with their diploma – allowing them to stay and work here in the United States.

As Fred writes:

Do yourself a favor and read the entire speech. It’s not long. Mike lays out a sensible and intelligent way to reform immigration laws without getting into the contentious issues that have held back immigration reform for many years. And if you agree with the Mayor, do everyone a favor and call your elected officials in Washington and tell them you are also for intelligent immigration reform (as opposed to comprehensive immigration reform). I’ve done that and it has helped. Getting your voice into the chorus on intelligent immigration reform would be helpful too

One thing is clear – our visa and green card processes are broken.  There is no transparency, and no predictability.  And we’re losing out on a lot of talent and a lot of well-educated graduates (arguably bad process outcomes).

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”

I need to write a post explaining why the Lean Startup has relevance to BPM, in a logical, specific way.  But before I do that, I want to get the raw impressions and data I’ve collected from watching sessions at SXSW and then I’ll post my analysis.  Because much of this content is available on the web, the key attraction to the event was to hear it live, rather than Memorex – much of the analysis is the same, but with fresh input.

Eric Ries kicked off the SXSW Lean Startup event with a good introduction to Lean startups.  My notes from the session (rough notes):

• Entrepreneurs are everywhere
• Lean Startup is about Validated Learning:
  • Build
  • Measure
  • Learn
• (scribbled something about innovation)

Next, Eric talked about Scientific Management, and Fred Taylor. On the one hand, a scientific approach to business is generally a good thing, and on the other, his approach falls on its face in startups.  The argument seems to be, that in startups, we would collectively benefit from a more scientific, rigorous approach (rather than the trial and error that often happens, and rather than the waterfall approach we often see).  But also, that scientific approach has to account for the fact that the both the problem and solution are not well-known. Taylor assumes the problem and solution are well understood.

The key idea is the Pivot.  His example:  Groupon was building “petition++” and made a huge pivot to daily deals.  Their first daily deal was for pizza at the pizza place in their building.  A very humble beginning, but also a very useful way to start testing their concept in the real world.

So the goal is to reduce time required to pivot (rephrasing: reduce the time required to learn what you need to know, so that you can pivot effectively sooner rather than later).

The Waterfall/Taylor approach just doesn’t work well in startup land (I had visions of Phil Gilbert’s old bucket brigade slides when I saw Eric’s slides).  Eric points out he was kind of annoyed to find out that even manufacturing doesn’t follow a Tayloristic approach anymore – they’re using Lean.  So why are people teaching software and engineering still teaching this approach that is proven to be wrong?

The problem with a waterfall approach: Achieving failure, on time, on budget, with high quality, good design.  Only one problem:  wrong product.

Deming and Ohno put the focus on the customer, and lean manufacturing as the way to get there.

Customer Develment + Agile Development

Agile Development was a big improvement to delivery models for software companies.  But even agile doesn’t work well, by itself, in startups.  It needed to be paired up with Customer Development (Steve Blank’s process for hypothesis testing your business model, at right).  Meanwhile, it becomes clearer when to employ the two key parts of a lean startup: the approach to unknown problems, and the approach to unknown solutions…

Unknown Problem, Unknown Solution

Not that executing these two models is necessarily easy, but it sure is a whole lot easier to do right if you know which situation you’re in.  If your problem is known, and solution is unknown, Agile development is a good choice. But if your problem is unknown as well, then you need to employ the customer development process to dig into what problem you’re really solving.

Eric described the cycles at IMVU, by way of example. And explained that the “pivot” is one cycle through the “build-measure-learn” loop.  A great quote was that “learning is the fundamental measure of progress” in a lean startup – not revenue, or users, or any other metric that a typical board might latch on to.

Translating to BPM terms: The pivot in business process management would be when we take what we learned from our last process improvement, measure what is really happening, and identify the new opportunities and tackle those.  In BPM we’re not pivoting the company hypothesis, just the hypothesis for where the bang-for-the-buck is in the process.

I particularly like his coverage of Lean myths:

1. Lean means cheap. On the contrary, lean is about speed much more than about cost.
2. Lean Startup is only for Web2.0 style companies. Actually, Lean Startup applies to all companies that face uncertainty in what the customers will want.
3. Lean Startups are bootstrapped. In fact, many lean startups are ambitious and can deploy large amounts of capital (see, Groupon).
4. Lean Startups replace vision with data. Actually, lean startups test the vision with real data. They still require vision!

Eric’s talk was followed by case studies on pivots by Pascal Louis-Perez (Wealthfront), Ash Maurya (USERcycle), Parker Thompson (Pivotal Labs).

Perhaps the most interesting nugget from these three case studies, with respect to the customers BP3 works with – was Pascal’s presentation on Wealthfront.  His company processes manages over $180MM.  And yet they have a continuous deployment setup – meaning they deploy changes to production as much as 30 times a day.  Their company puts lie to the idea that a highly regulated industry with very important financial outcomes can’t adopt a continuous deployment development model.  I’m not advocating that every Fortune 500 company do the same with BPM – but clearly there is a happy middle-ground between 18-month roll-outs and 30 times a day…  And whatever your number of days between deployments is, we should be looking at ways to reduce that number.

Ash Maurya was up next (slides here), and I admit to being surprised when he presented the use of kan ban boards to visualize the workflow of feature ideas (this is, truly, treating development of product as something that can be measured and improved and understood). He advocated moving only so fast as you can learn or aid the process of learning – that moving faster than that, or slower than that, amounts to waste (a big no-no in Lean thinking).

Parker Thompson, of Pivotal, advocated having a vision, but being humble and pragmatic in the near term.  If testing with users or customers proves that your vision isn’t getting traction, don’t assume you have the wrong test subjects, be willing to revisit your hypothesis and test different ideas.

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!).

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.

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.

Eric Ries’ presentation on “The Lean Startup: a Disciplined Approach to Imagining, Designing, and Building New Products” has three processes depicted for “product” development.  I put product in quotes because I think you can accurately substitute “service” or “process” and the presentation still applies very well to the situation if you assume that some technology or other development activity is required to support your service or process.

Here’s the presentation, but allow me to call your attention in particular to slides 20, 21, and 22.  In slide 20, you see the traditional waterfall strategy, which Eric explains is appropriate when you know the problem well, and the solution is also well known and understood.

In slide 21, we see an Agile approach, where the problem is known, but the solution is not well-known and understood.  In fact, a decent number of agile projects get into trouble because the problem is not well-understood and they get caught in what feels like “churn”.

In slide 22, we see the introduction of the Customer Development Process to the mix, and the situation is one where the problem is not known, and the solution is also unknown.  So part of the journey is to discover the right problem to solve, as well as the solution that solves it.

I think a lot of BPM projects would do well to adopt this third method (or an adaptation of it) as well.  At a high level we may know that there is a problem (opportunity), but we may not understand what that problem is at a detailed level that would allow us to design a good solution.  So we have to do some level of customer development (in our case these may be users) to understand the problem adequately, and then use an iterative approach to get the proposed solutions improved and adapted as quickly as possible.  At the very least, when taking on a BPM project, one has to keep an open-mind to improvements that haven’t been thought of, and to new problem-identification that may happen over the course of the project.

A blurb about the slideshow is available on O’Reilly here.

Also, a more in-depth presentation was done previously on the Customer Development Methodology:

This version goes into a lot more detail on how to build the startup around this methodology, and makes a stronger case for why you need to iterate between business plan and hypotheses before funding, rather than proposing a business plan, getting funding, and *then* testing the market… its a good read!

There’s a really thought-provoking blog on startups, Lessons Learned by Eric Ries, and in a recent post he details his thoughts about “the Launch”.  His advice in a nutshell:  Don’t Launch.

It sounds so counter-intuitive when so much of the hype and mystique around startups is about The Launch.  Much like The IPO, or The Liquidation Event, it seems inextricably tied to the process of starting up:

1. Draw business plan/product idea on paper napkin
2. Get angel funding
3. Build out slide deck and prototype for investors
4. Get Series A Funding
5. Launch
6. Build virtuous hype cycle
7. Go public

Or something like that…(YMMV)  However, Eric points out that most people conflate the announcing of a new product/service with the making of that product or service available to the public.  It turns out, he is advocating to do the latter – make your product or service available – without the marketing launch.

He makes compelling arguments:  that the launch is a tactic, rather than a strategy.  He points out that there are pitfalls to a launch, as well as rewards (for example, mis-positioning, and setting expectations unrealistically high).

What Eric does a really good job pointing out is that your time and energy in your startup is much better spent on improving your product and service offering, on iterating it, and building up your operational capability, revenue stream, pipeline.  In other words, focus on the basics of running a business.  Don’t focus on the Launch. Put into process terms:  the Launch is a step (tactic) that cannot ensure success in the process of building a successful startup.  It turns out that you need to focus on all the more process-oriented aspects of your business:

• Product Design & Development
• Service Design & Delivery
• Sales
• Operations, etc.

Some would say this is focusing on substance over flash – and isn’t that pretty appropriate for a process-focused professional? After all, when the process is the star of the show, there’s a little less glamor, but the bottom line results speak for themselves, and those results are generally sustainable over a longer period of time- launching isn’t something you can do well in a repeatable fashion for your product- its a one-and-done moment in time.  And as a result, as Eric points out, the risks associated with this single tactical action can be negative, but the positive side is a temporary boost if all goes well.