Monthly Archives: June 2010

Fail slower


Disclaimer: I feel a great philosophical affinity to the lean startup community, although I wouldn’t necessarily call myself a card-carrying member of the club.

I’ve explained in my previous post how despite an unfavorable expert opinion we decided to keep going with just❤liked. Your comments, which are as welcome as ever, have given me a little more time to think about whether there was some message in there for the greater lean startup community.

Let me just come out and say it: Yes, I am trying to coin a phrase. So as unfortunate as many misinterpretations of the meaning of “fail fast” may be, enter

fail slower…

The point of fail slower is that you should not fail too fast if it means that you miss out on an important swath of knowledge which has to do with learning what doesn’t work.  I am convinced that there is value in this kind of learning as well, and for first-timers like ourselves these insights are of critical importance. Something has to feed and inform the pivot (couldn’t resist) and it has to be learning-based.

I should clarify what I mean by learning here. Have you ever tried to learn how to program by reading a “Learn X Programming in 72 Hours”? If so, you should know that this stuff (1) is no fun and dry as hell, (2) doesn’t stay with you, and (3) has not given the world its best programmers. What I am trying to say is that someone telling you something is a different kind of learning from first hand experience, search, discovery, wrong turns, running into walls and tearing your hair out by the roots. And if it means you have to fail slower to tap this knowledge, I am fine with that.

PS: I know the situation would be a bit more complicated if you have investors footing the bill. I am not suggesting you learn this way at someone else’s expense.  Also I imagine that if you have investors to begin with, you’ve already had a chance to do this learning at some point in the past and you’ve done it well enough.


Startup – the anxious business of business building


There are many possible motivators for starting your own business. Whatever they may be it’s still a viable business that you are after. It’s not a hobby or a diversion or a side project, it’s building a business that is the ultimate goal behind starting a startup. The other goal, one that is no less important, is to learn as much as you can about business building itself.

It should come as no surprise that when you set up on your startup journey, you set off with a set of proposed assumptions and inherent biases that you then work to prove.  I claim that proving existing assumptions wrong and finding new patterns that have no prior assumptions attached to them have different emotional implications for the founders. Even though “customer development” and “validate everything early and often” are all the rage, we still tend to hold our assumptions and biases as something deeply personal.

Well, last week brought a sobering of sorts. The assumptions that my co-founder and I have considered provable have come under harsh scrutiny of an outside expert, someone I trust and someone who has a solid track record of success and beyond-doubt credibility in this space. You may call it a watershed event, a cold shower – as my cofounder called it, but it was certainly, in its immediate aftermath, a source of great anxiety, concern and new doubts.

We heard the feedback, but we decided to keep going because we still believe we are working on something worthwhile. Expert opinions are expert opinions, but they lead to no revelations. Learning leads to insights, and if it takes another couple months for our users to second the expert opinion it would carry that much more weight in our minds. I think the users should be the ultimate judges of our undertaking. Also, it is my sincere hope that engaging with users will lead to more insights than a simple thumbs up or thumbs down from an expert.

Are we as surefooted as we were a couple of weeks ago? No, of course not. We always had very little surefootedness to speak of. Are we ready to throw in the towel and turn the project that we thought was a business into a hobby? No, that’s not what we intend to do either. We still feel that justliked was worth starting both for the sake of the learning experience it affords and as a business we believe in.

Product Management and “The Other White Meat”

Let’s start with a Wikipedia definition:

Typically, “pork” involves funding for government programs whose economic or service benefits are concentrated in a particular area but whose costs are spread among all taxpayers.

This week (for my day job) I attended a recurring gathering of companies meeting to decide what the next low-power wireless standard is going to be like. The subject of this post has nothing in particular to do with professional conferences or low-power wireless standards. You can go through the exercise and replace ‘companies’ with ‘stakeholders’  and ‘low-power wireless standard’ with ‘feature set’. In fact I want you to go through the exercise since it’s unlikely that low power wireless is of any relevance to you.

The highlight of this gathering was an intense debate about the choice of a particular component. Several alternatives were offered and dissected in nauseating detail. In the end the majority seemed to coalesce around one of the choices. In fact when the vote was taken more than 3/4 of all participants voted for it.  That choice was then committed as a mandatory requirement, i.e. any product implementing the spec would have to implement this particular component.

I would expect that to be the end of it. However, what happened next was that one of the companies suggested that the runner up, which only 1/4 of the companies voted for in the first round, should also be entered in the spec as an optional requirement, i.e. a product implementing the spec could implement the other component, while still implementing the mandatory one.

The argument offered in defense of this addition was that the company had a large customer who insisted on the runner up option, and although said company would have preferred for it to be mandatory, they wouldn’t mind implementing both if they have to. Remarkably a lot of attendees found this line of reasoning convincing and proceeded to vote for adding the second choice as an optional requirement. After all, they already got what they wanted.

The fools! What nobody seemed to notice was the by bloating the spec with optional components that nobody by a few companies cared about, everyone was footing the bill.

Product architecture

Why do I think this seemingly harmless addition qualifies as pork?

  • Bigger spec means bigger test plan and more resources required by all vendors during verification and certification of their products. Likewise, interaction of optional and mandatory features often leads to subtle bugs, increased complexity and everything that follows.
  • We are talking about a wireless protocol spec so optional features tend to affect even those products that don’t implement them because everyone has to at least be aware of all the options.  Ironically enough, one of the most important criteria for the original choice was its small code size, so the optional feature actually devalues the mandatory one.
  • By voting for to make the runner up an option, all vendors effectively assumed the responsibility of  explaining to their customers why their product does not implement it all. The majority has done itself a disservice by automatically putting itself on the defensive.

A product manager’s job is rife with this kind of minority-staged shenanigans. The boss wants to turn all yellow buttons into green ones. A vociferous user wants an arcane API hook. Engineers want it in Ruby. The compromises that we succumb to today may seem innocent enough, but that’s only because we thought about them for the whole of 5 seconds or while still intoxicated with our previous wins. And so on our watch and with our own timid approval, the spec, the requirements document, the backlog, whatever it may be at your organization, starts to get weighted down with pork.

As product managers our job is to optimize the resources to build the greatest possible value for the product that eventually hits the market. In light of this, it’s a no-brainer that every piece of pork should be viewed with extreme caution and as a possible threat to our most important function.

Letting down our guard and giving pork a free passage means that we too sign up to foot somebody else’s bill.

Structured discovery, social media, and game dynamics walk into a bar


Structured discovery is a set of steps by which a user interacts with an application to discover something new and, if the stars are aligned, something valuable. Even the most immersive worlds of modern 3D games have their rules. Levels generated on the fly still obey some designer’s intent for the user to see things in a certain order and at a certain pace. A Twitter user three degrees of separation away will take 3*a+b mouse clicks to find, assuming you click here, scroll all the way down here, click there and so on. You get the point.

Think about a kind of “value map” or “reward map” for your application. Where is the value concentrated for your users? What motivates the users to jump through the hoops and obey all the rules and how many hoops can they tolerate before getting frustrated and leaving? Is it the process of slashing monsters or the progress to the next level that is most rewarding?


Continue reading