Archive for the 'Strategy' Category

Watching Dave McClure‘s presentation today, I started to think about how a lot of the lean startup and customer development folks talk about creating the Minimum Viable Product (MVP), Release Early / Release Often, Product / Market Fit, Pivoting, etc., etc., but there’s very little talk about choosing your market or your product strategically. (At least not that I’ve noticed, feel free to correct me.) I’d like to read that blog post.

A lot of the advice out there ultimately mitigates risks. Here is my horribly unfair summary:

• Minimum Viable Product (MVP) – Spend less on creating your product, therefore you are risking less time and money on a bad product.
• Release Early / Release Often – Learn in small increments, therefore you are risking less time and money on a bad product.
• Product / Market Fit – Either change your product to fit the market or choose a different market for your product before you start spending money on marketing, therefore you are risking less time and money on a bad product.
• Pivoting – If you have a bad product, change it to something else.

All of which is great advice which this summary does not do justice to. Still, I’d like to read about how to choose the product that needs iterating. Unfortunately, I can’t claim the knowledge to write that post in detail, but I think it should go something like this:

• Before you start executing on plan A, think of plans B-D

Come to think of it, that’s a really short blog post… maybe it should just be a tweet. Here are some other options:

• 90% of winning the battle is tactics, but winning the war takes strategy.
• Stop. Think. Then act.
• Just because you create a product in a weekend does not mean you should.

A lot of this is implied in Eric Ries‘ posts on pivoting. Pivoting is a great tactical maneuver that goes back centuries. Put simply, if no one likes your product, what is the smallest possible change that may enable a different use case / selling proposition? Much of the backing for this proposition comes from Eric’s philosophy which reduces the cost of developing a product so radically  that to change a product or start a new one is insignificant and essentially zero. Perhaps for web 2.0 entrepreneurs this will work well. However, I don’t feel this is sufficient, especially not for brick and mortar folks. I believe a lot more thought should be put into determining tactical and strategic options before you write a single line of code. That additional thought is certainly not going to impact development costs, and may radically improve your ability to pivot later.

Shortcuts for my Poor Poor Brain

I take much of this from chess. Being far beneath the master level and unable to think out 12 different scenarios 12 moves in advance, I have to take a lot of thinking shortcuts to have any chance of winning. My favorite cheat is, “If I pursue this option, will I have more or less options on the following move?”

At the risk of alienating everyone who hates chess, here’s a chess example. Which side has the better position? White and black have the same number of pieces so that’s not relevant. In this highly unrealistic example (neither side could win if this was a real game) white has the better position. Without even knowing the basics of how the pieces move, you can guess that white has the better position because it’s knight is in the center of the board and it has a lot more options in terms of where it can go next. In terms of possibilities, white’s knight has eight possible moves whereas black’s knight has only two.

Don’t like chess? Ok, here’s a more down to earth example. Would you rather go to a restaurant with 8 items on the menu or just 2? If you happen to know that the restaurant with 2 items is the French Laundry and the other one was a shady looking diner, then yes…you should choose the French Laundry. However, in the absence of additional information, you should probably pick the one with more options. You’re more likely to find at least one thing on the menu you like, especially if you’re a vegetarian.

This basic principle applies to pretty much everything including martial arts, warfare, and yes…product development. If the product you are building has no tactical or strategic development options after you create the Minimum Viable Product, then it is not the right product to build.

Minimum Viable Strategy

Manuel and I first got together with another colleague, Florian Leibert, to create an IT security product which we tentatively called LOK (Leibert, Offenberg, Kromer) which we all thought was a cool idea, but probably unwise to build. Without going too far into details, it was a replacement product for PKI which would allow a cheap, easy to use cryptography platform based on P2P trust networks. In non-geek talk, it was a thing that replaced an expensive thing with a cheap thing. Among many other problems with the concept, the biggest one was probably that if it didn’t work, there was no direction which we could pivot to.

Could we pivot the product to a different market? Unlikely, the product was meant for a very specific set of security conscious, technology literate enterprise customers. Could we pivot the feature set somehow? Perhaps, but it would essentially be like creating an entirely new product from scratch. Could the feature set be somehow reduced to be less risky? Not really, the product required a serious amount of infrastructure just to work in a basic use case. Was the product incredibly cool and do I still want to build it? Hell yes, but I’m not going to.

Manuel and I spent a lot of time shooting down well over a dozen ideas for one reason or another. But a lot of the times the reason turned out to be, “What if it doesn’t work? What are our options then? How many tries will we have to get it right?” Eventually, we settled on startupSQUARE.com because it has a number of interesting options that I won’t go into here. So I’m sticking with this one and I’m still asking, will someone please write about Minimum Viable Strategy?

Cheers,
Tristan