ladies and gentlemen, what's your business model? Part #2

Following Part #1, here's a build-a-business-model... eh, model:

First of all, a strategy is a must; freely gleaned from Professor Porter at Harvard Business School:

"What value are you to deliver to what customer and how are you going to be different from your competition."

Now, to the Business Model design:

1. Rethink the value.
The value you are to deliver is supposed to solve a problem. Revisit the problem definition, ask "what for?" until the core issue is laid bare.
Guiseppe Delena at Ford (from Fast Company June issue) puts it nicely: "Don't tell me you want a bridge, show me the canyon!" A bridge is good if the canyon is unavoidable, but sometimes it could be as simple as using another road.
This may lead to a slight rewrite of the strategy.

2. Clarify the parts.
Map the resources needed, the natural process sequence and include absolutely everything. Product development is after all just another process within the whole, not a separate one-time experience. Ditto for production. Customer interaction as conversations have to include the customer in some manner. And so forth.
Most important: Do not limit yourself to anything at this point, do not set borders - suppliers, outsourcing, advisers, funding, customers, employees - all resources you may need. Ditto for processes, stick to one holistic flow for the moment, split it later if necessary.
Did I mention that you should forget the structural stuff for now? Hierarchies, titles like CEO, CTO,CFO, VPs and so forth? Focus on 'required resources', add titles and structure later.

3. Check out the competition.
What are they doing? Anything useful there?
Keep this information for a comparison with your Business Model in progress later. See similarities as danger signals.

4. Prototype the Business Model.
Map a natural flow: Where does it start? Where does it end? What happens in the flow?
Place the required resources in that one-single-flow. Find a practical solution to how the process will happen in real life terms, i.e. how are work-orders delivered, how are resources delivered and readily at hand.

5. Smack some structure onto it.
If you have the answer to how the process could work in real life terms you already have the answer. If not, try 4. again.
Did I mention, do not fall into the trap of automatically using old hierarchical models?

6. Test the prototype.
Going to market full blast is never a good idea. Appreciate a slow start, that gives you ample time to get feedback from real customers, then go back and make better and repeat.
Do not think that a product or service ever was used, bought or perceived exactly as planned.

7. Iterate.
Keep the Business Model loose enough so you can change and tweak immediately upon customer feedback. Spending a million on advertising at this stage cements the Business Model. Hiring-to-fill-positions and setting structure in stone leaves not much room to tweak. Hire for resource needs, not hierarchical needs.
Stay loose, have all stay loose.

8. It gels.
It could take weeks, months - but prototyping a loose Business Model may give you a real life tested and good Business Model. And that's not a bad idea.

9. Revisit.
Have mechanisms in place to question the whole Business Model at all times, do not settle for tweaks to little parts like ads, wording on web page or number of sales people. Be holistic, look at the complete process, take nothing for granted.

[EXAMPLES: Dell did not take over the 'design, produce then sell PCs' model for granted, they started off with a customer ordering, rearranging the process. Check out what Amazon, Southwest Airlines and others did, some of the same all-the-way-down to the core approach when building their Business Models from scratch.]

[DEPARTMENT OF IRONY: The above list amounts to yet another model and should thus be tested, iterated and changed at will :) Expect some follow-up on this.]

Comments

[Ric]

So Sig - are you eating your own dog food here? Is this blog part of your own step 6? ... or step 4?

Does the model explain why you are developing Thingamy, or are you looking for a model that will support Thingamy now that you (almost) have it available?

Whatever - I like the iterative nature, and the 'release early, release often' flavour (or is it 'fail fast, fail cheap'?), even though it isn't open source (yet?). Also by not tying yourself up in structure too early (which many new businesses do) you avoid having to jump irrevocably into the brave new world of self employment - the first few steps can be taken from the 'security' of paid employment, until the prototype model is tested/adjusted.

I look forward to the next instalment ...

[sig]

Ric, hehe, of course I eat my own dog food here!

As the software is a kind of manifestation of the ideas, or even an idea amplifier - then blogging is more than important, it's essential.

It would be a combination of 1. and 6.
Discussing the ideas and reading other related stuff is extremely valuable in order to understand where people (the market!) have issues in their corporate life and what is important for them. In other words an excellent way to check, recheck and tweak our value assumptions in #1.

Given the close relationship between the ideas and the product, then blogging and discussing is in essence a product-less launch :-) that gives instant feedback for #6. Very useful, and damned fun! Cheap too ;-)

And yes to both next ones: This is why we build the software so you can change the business model on the fly and every day. And yes, this is pretty much the way we handle ourselves when we inch forward. Dogfood :-)