coneblog

At a lecture by Adam Nash, Director of Product at LinkedIn, I got some insight into what makes a successful Web 2.0 venture. I have divided his comments and concepts into seven lessons for the Web 2.0 entrepreneur, with my personal embellishments:

1. Understand your target market: Know your users and your demographic. It’s not what you think is cool, but what they think is cool. And if they is everybody, and you don’t have $50m to reach them, segment the market;
2. Don’t wait: Don’t wait until you product is perfect, get it out there, experiment, and get some real market feedback. The best antidote for Eight Guys in a Room syndrome.
3. It is all about Distribution: If you build it, they won’t come. Unless they see you as a natural progression from something they are already doing. That last sentence includes See – they must see you, and Progression – must be new, but connected. Almost no one can afford to create distribution on their own, so think about how you can leverage existing networks, sites, and communities. From the outside, the excitement over Facebook and OpenSocial is about distribution.
4. Order is important: the path to web success is a sequence of problems and solutions. The order that you take them is important. Don’t obsess over your shopping cart UI until you have users who want to buy. Think about what comes first.
5. Timing is important: you can have the right idea, and the right implementation, but be too early or too late. LinkedIn was almost too early – business professionals in the broader market weren’t ready to network on the internet. But some key industries and cites were, which created critical mass.
6. It is a platform business: At the core, the value in your business is the value in your product platform: its features, robustness, agility. Its not the Brand. Seth Godin points out that Brand is a weak substitute for customer relationships. In a quickly moving web 2.0 world, your brand is only as good as your ability to service the needs and wants of your customers. Those needs and wants are fickle. A platform focus allows agility, collaboration, openness. From the inside, the excitement over Facebook and OpenSocial is about platform. Adam must be an old school developer, because he believes, as I do, that value in platform is all about your data model.
7. Keep coding: Someone asked, how do I keep The Big Players from stealing my great idea. Adam suggested that you had to keep making your product better. I’ll paraphrase Thomas Edison, and say that success is ten percent idea and ninety percent code. Make a great product, then keep making it better.

Failure is inevitable. In fact, some of our most successful role models have made organized failure a part of their achievement plans. Thomas Edison, the patron Saint of Failure, famously said, after his 10,000 th failure at finding a filament material for the electric light bulb – “ I have not failed. I've just found 10,000 ways that won't work”.

I call effective use of failure the “Fail Forward” technique. Here are ten barriers to the effective use of failure:

1) Talk it up to your family, relatives and friends – This is a barrier, because it makes it hard for you to stop, adjust, or go in a new direction. Your sister-in-law will come up to you at a barbeque and ask how things are going, and you will have to smile and say, “just great’.

2) Fail slowly – the power in effective failure comes from learning from your failures, and trying again. Hanging on, staying the course, never giving up are all barriers to effective failure. I’ve learned to temper my tendency to persevere, and ask the question “is it time to pull the plug”?

3) Take it on the road – relocation involves a huge commitment of time, money, and mental bandwidth. Moving for an opportunity is very visible, and hard to undo. Be careful before you commit to a project, job, or opportunity out of town – it is much harder to exit once you have made that commitment. As Shirley McLaine famously said about her loser son-in-law in the movie “Terms of Endearment” - “He can’t even fail close to home!”.

4) Name it after yourself – I’ve made this mistake – naming it after yourself (or your mother, wife, or child) can be a good thing, in that you affirm your commitment to the project, and your love for the person. But it can be a real problem when it is time to bail. Who wants to close a company named after their mom?

5) Over Plan – Another personal problem. I’m a planner by nature, and I like everything about the planning process. I like to envision the future, I like to keep options open, I like to consider alternatives, and form the possibilities. This, of course, gets in the way of actually doing something! More is gained from engaging reality than from considering the alternatives in a planning way. Under-plan, and over-try.

6) Don’t Document what you did – If you don’t document what you did, and why, you can’t engage in the all-important review process afterward, where you compare your execution with your results, and adjust accordingly.

7) Don’t Track your Results – If you conceive, plan, and execute, then don’t track your results, how can you fail forward? How can you understand what worked, and what didn’t? How can you adjust, and retry? Make sure that your trails and failures are set up so that you collect the key data.

8) Give Up – Effective failure is all about “try, try again”. If you get discouraged, or distracted, or go on to the next thing, you can’t learn from your mistakes. A single trial in a sequence of projects or efforts is much less effective than a set of focused trials that build on successive successes and failures.

9) Spend lots of money early – the tendency in many project efforts is to “front load” – get a good start, prepare against inevitable delays, and make good early progress. The problem with front loading a project is that you may not know where the problems will appear. In many cases, it is better to “keep your powder dry”, and save resources for the problems.

10) Keep doing the same thing – you have only failed forward effectively when you adjust your actions, your approach, or your goals based on what you have learned.

Larry Cone

BTW - Here are some Useful books and tools for the project manager:

Link to PM Items.

There are aspects of SAAS that I hadn’t appreciated, including the need for reliability.

In SaaS, you have the ability to have various dummy organizations right in production for various reasons and situations, everything from Demo to Testing. The reference system is production. If you want to understand how a certain feature works in a special configuration, you can try it out in a test organization.

Of course, this requires a high level of reliability in all aspects of the system. I pleased to say that we have that level of stability in our production environment. That is a result of the hard work of a relatively few people over the last six or seven years making the system rock solid.

Click to read more ...

I’ve picked up stakes and moved to a new gig, where I’m seeing the power of the Software as a Service model.

Yes, it’s true. I’ve left the challenging world of Health Care Clinical Applications for the heady frontiers of SAAS, applications delivered right to your browser without muss, fuss or your own infrastructure. It’s a whole ‘nother world, and I’ll pass on what I’ve learned so far.

Click to read more ...

Reflections on the possibilities and realities of the Software game, and the need to say No.

No is a useful word. In child rearing, it sets boundaries for the child. Boundaries that are desparately needed by a toddler who is trying to assert his independence in a huge scary world, and who needs you to set some protective barriers.

No is also valuable to the teenager, who needs to be protected from his or her own urges and needs, and who needs to know that you value her so highly that you will fight her to keep her safe.

And No is an essential component of a software product strategy. I read Susan Mernit’s Post on no  the other day, and was struck by her insightful comments.

As we all know, you can do anything with software, given enough time and money. But that’s the rub, isn’t it – we need to function in a time and resources bounded world. So we need to say No to everything in the universe of possibility in order to accomplish our small thing.

I typically rage against the No. In my passion to deliver great software to my customers, I want to give them features that they need. And I’m all too aware of the long slow delivery cycles, and the possibility of not getting another chance. I typically go the “make the pie bigger” route – looking for ways to improve productivity and/or cycle time to deliver more. Or to be smarter about prototyping and cycles so that the application delivered is its lapidary best. (characterized by an exactitude and extreme refinement that suggests gem cutting: a lapidary style; lapidary verse).

But, even I give way to the need to exclude in order to include, the need to say no. Susan cites some common reasons for this in product development:

• The project isn't something we have the resources to do right now--and it's not worth prioritizing over something else
• It's a nice to have, not a must have
• The level of effort and the return don't line up enough
• It's distracting from our core business objectives--for the year or the quarter
• It's overbuilding--we think it's neat, but customers won't notice
• It's too bleeding edge (this is a subset of overbuilding)--we love the idea but the novelty outweighs the business impact

These are all good reasons. In the face of cool features and impassioned supporters, it is hard to sort out. But sort we must, because we have to say no a hundred times for every yes.