The Lean Startup workshop coming soon

I am currently gearing up for my talk tomorrow at the Web 2.0 Expo (last day to register to go for free, incidentally). I've been working on my presentation, but also on a new project I'm planning to announce there. Readers get an early sneak peak.

My overwhelming takeaway from the most recent Lessons Learned survey is that there is tremendous hunger out there for in-depth opportunities for entrepreneurs of all stripes to develop their lean startup skills. As you can tell from recent posts, I've been experimenting with different formats and channels to try and find the best way to help. And today I am excited to announce a new experiment: the Lean Startup workshop.

I don't want to go into too much detail in this post, because (as usual) I want to invite anyone who is interested to take a new survey specifically about the workshop. It's designed to take less than ten minutes, and I appreciate those who are willing to donate their time in this way. Thank you.
Click Here to take the survey
Lurking at the end of the survey is something new. If you've been following my efforts in figuring out the best way to evangelize the lean startup, you'll know that I am trying to apply customer development principles. And if you know those principles, you may notice that I am trying to pass from the "customer discovery" phase to the "customer validation" phase. I won't say any more, for fear of ruining the data. But look for a future post on the topic using the data you all help me collect.

See you at the Expo!

NB: if you're already sold on the workshop and would like to pre-register, click here.
Reblog this post [with Zemanta]

0 comments:

welcome to my blog. please write some comment about this article ^_^

Cash is not king

Cash on hand is just one important variable in a startup’s life, but it’s not necessarily the most important. What matters most is the number of iterations the company has left. While some cost-cutting measures reduce that number, others increase it. In lean times, it’s most important to focus on cutting costs in ways that speed you up, not slow you down. Otherwise, cutting costs just leads to going out of business a little slower.

The full formula works like this:

runway = cash on hand / burn rate

# iterations = runway / speed of each iteration

Very few successful companies ended up in the same exact business that the founders thought they'd be in (see Founders at Work for dozens of examples). Some aspects of the vision remain, but often in a significantly modified form. Unfortunately for the current crop of founders, there is intense pressure to engage in selective memory when companies tell the story of their founding. Journalists, PR firms, investors, and the public at large love a scrappy come-from-behind story about two guys in a garage who figured out how to take down Goliath. But the story usually features visionary protagonists who had it figured out from the start. Explaining that half of what these visionaries thought in their early years bordered on delusion tends to be a hard sell.

These successful startups managed to have enough tries to get it right. As a member of a startup, your incentive is to do everything possible to maximize the number of iterations you have left. What counts as an iteration? I believe it is a full, company-wide turn through the OODA loop (for a software business, see especially Ideas-Code-Learn). Minor experiments and variations don't count, although they are helpful. The key is to be able to refute as many major hypotheses as you can. We're talking PayPal-sized variations.

To increase the number of iterations you have left, you can either increase cash on hand (by raising money or increasing revenues), reduce burn rate, or increase the speed of each iteration. The most powerful changes you can make affect the speed of iteration. Even more powerful are costs that currently slow you down – by cutting those you can get the double-whammy benefit of lowering burn and increasing speed.

The key is to examine every cost through the lens of its effect on each stage of your learning feedback loop. Even if it helps optimize one stage, if it slows you down somewhere else, it might not be a net win.

The hardest costs to cut are those that are embodied in sacred cows. For example: we have to have strong documentation for our internal API's, else we might not be able to have third parties use them in the future; we can't afford to ship a low-quality product to our customers, because it might diminish our startup's brand image; we can't charge for our product until it contains Essential Feature X; we have to have a dozen managers sign off on every proposed feature, to protect the integrity of our product. Each of these might be good policies, at least for one stage of the feedback loop. Once they attain sacred status, they are rarely questioned. A crisis is sometimes needed to force that reexamination. In fact, every single lean transformation documented in books like Lean Thinking took place in the midst of serious external threats.

You cannot become a lean startup by willpower alone, any more than you can lose weight by going on a willpower-based diet. You need a process for systematically reviewing your costs and eliminating those that slow you down. In fact, the essence of many of the practices I have learned is to take systematic advantage of the power of crisis to spur creative thinking. This is why I constantly stress the need to set specific, actionable targets for new product initiatives or new feature split-tests. You cannot learn if you cannot be wrong, and vague goals are exceptionally easy to rationalize as success.

So how many iterations do you have left? What could you do to squeeze out one more, just in case your current plans don't pan out? For some specific suggestions, I recommend:
And, of course, there's the Lean Startup session at the upcoming Web 2.0 Expo, for those that are interested in discussing these topics in depth. As a reminder, you can come to the session (and a lot more) for free, courtesy of web2open.

0 comments:

welcome to my blog. please write some comment about this article ^_^

The Lean Startup at Agile Vancouver April 21st

A surprising number of respondents in the latest Lessons Learned survey hail from one of the flourishing startup hubs in Canada. Who knew? In order to reduce my incredible ignorance about other such hubs, I'm heading to Vancouver.

In keeping with my recent theme of blogging about upcoming events, I'm happy to announce that I'll be speaking at Agile Vancouver on April 21. (For those of you who subscribe to the blog for substantive content and whatnot, I promise to get back to more regular posts soon. And when did there get to be 3000 of you? Thank you so much!)
Agile Vancouver: Lean Development for Lean Times
On Tuesday April 21st, we are hosting an afternoon event on the application of Lean Principles to software development. This workshop brings together leading thinkers from Lean Production and Lean software.
Please register to attend this event as space will be limited.
I'll be speaking about the lean startup in what I hope will be a more interactive setting than the usual lecture-with-slides. It will probably be the first time I'll be able to take extensive Q&A on some of the new frameworks I'll be debuting at Web 2.0 Expo. As always, if you decide to attend, please come say hello. If you can't come but have a burning question anyway, please leave it as a comment. I'll do my best to respond.

0 comments:

welcome to my blog. please write some comment about this article ^_^

Lesson 50: Be A Courageous & Confident Beekeeper




Hello from David & Sheri Burns at Long Lane Honey Bee Farms in East Central Illinois.

I once asked the audience at one of my presentations to give a show of hands as to how many were raising their own queens. No hands went up. I asked a second time, because I thought maybe they didn't hear me. Still no one. I was amazed at how few beekeepers raise queens. And yet the queen is the most important bee in the hive. No doubt, a lack of courage and confidence in raising queens keeps many beekeepers from attempting to raise their own queens.


Many beekeepers never really become beekeepers, but only remain bee-havers. They have bees, but they really don't work or manage their bees. There are many reasons why people remain bee-haves and never become beekeepers but I think one of the biggest reason is FEAR and a lack of courage. The second reason is similar and that is a lack of confidence. Many beekeepers just don't feel confident in knowing what they are doing. They are afraid that their lack of "knowing what they are doing" will result in doing something wrong and killing their hive.

This is why most beekeepers never raise queens. To them, the place where the queen lives is mysterious and so deep within the hive, a place where no man has gone before. Every year thousands of "beginner" beekeeping courses are given around the country. These are great to help beekeepers get started, but there is rarely a follow up mentorship or advance class.

As a result most bee-havers know enough to install a package, dump expensive and unnecessary medication on their bees, watch them die in the winter and buy packages the following year only to repeat the same techniques that may have led to their bees failing the first time. We've got to break this cycle!
With a bit more education and mentorship, a bee-haver can become a beekeeper and develop a level of skill, knowledge and confidence that can catapult their beekeeping hobby to a whole new level of success. Education is the answer. But no matter how "book-taught" a beekeeper is, the best education is through a hands on course.

Another way that you can build your confidence and courage in beekeeping is to catch swarms. Swarms rarely sting and always draw an audience. It builds your confidence to retrieve a swarm and place it into your bee yard.
Once people hear that you keep bees, they will be calling you asking you to remove a swarm. We've build a perfect swarm catch box so you can place the swarm in it and transport it back to your bee yard. Click here for more information. It comes with a screen to shut off the front entrance once the swarm is captured as well as a tie-down strap to hold it all together for transport. Every beekeeper should have one just in case your own hives swarm on you. You can catch them and keep them as a new hive.

This extra hive will build your confidence know that you have extra equipment should you want to raise an extra queen or keep a smaller hive going or to support an observation hive. Lots of uses. During the month of May, many beekeepers call us and want us to rush a hive to them because they found a swarm. But, by time the hive arrives the swarm has left. So have one on hand! It is worth the investment. It will nearly pay for itself in one swarm catch because you save the cost of a package of bees.

We are here to help you keep bees with courage and confidence!
Visit our website at www.honeybeesonline.com

And listen to our beekeeping podcast available at:
www.honeybeesonline.com/studiobeelive.html And if you have questions about beekeeping that you want us to answer on our next broadcast just email them to: david@honeybeesonline.com
Feel free to call at: 217-427-2678. Until next time, remember to bee-have yourself!

David & Sheri Burns
Long Lane Honey Bee Farms

0 comments:

welcome to my blog. please write some comment about this article ^_^

The metrics and levers of engagement, presentation on Engagement Loops for Facebook Developer Garage SF


I'll be presenting a talk at the Facebook Developer Garage SF Wednesday evening. You can learn more about the event here. It's hosted by Kontagent and sponsored by Intel. Most of the content for my presentation is drawn from my original article on engagement loops, with new diagrams courtsey of my friends at Kontagent and a few new examples. Without further ado, here are the slides (feedback welcome!):


When I work with startups on improving engagement, I really try to emphasize the importance of their most powerful lever: positioning. In most applications, most of the time, customers return to use the application not in response to a notification or event, but under their own volition. These decisions are critical to the success of any high-engagement product, and they take place entirely inside the minds of customers. Companies have an opportunity to influence these decisions, but only if they act well in advance of the result they are trying to achieve. Unfortunately, it's easy to lose track of positioning effects when optimizing for a single metric.

This is a common problem that results from viral-loop optimization. By copying the exact same registration flow as every other successful viral app, many viral apps completely lose their positioning. Customers can't even remember what apps they've signed up for, and become entirely dependent on notifications to bring them back. This starts a downward spiral: as more and more apps become indistinguishable, they send out more and more notifications, which leads to increasing fatigue on the part of customers. As notification channels get stuffed full of these messages, customers tune them out (or platforms have to put in place dramatic limits on access).

The solution for app developers caught in this vicious cycle is to develop competency in positioning. Luckily, a great example of the power of positioning fell into my lap recently. Some friends of mine at EA tried to break my World of Warcraft addiction by walking a copy of Warhammer Online over to my house. I dutifully installed it and played with them for a little while. But pretty soon the lure of WoW dragged me back, even though some of my friends stayed behind on Warhammer.

A few days ago, I received a great email from Warhammer Online. It's an example of an excellent synthetic notification. Take a look at this screenshot:


This synthetic notification gets everything right: it has a compelling offer and a clear call to action, it addresses me by my character's name, it's from a well-known NPC inside the game, it even includes the names of several friends who are still playing, and calls me to act on behalf of my guild (yes, it's called GUID). It then proceeds to list a whole host of cool new features the Warhammer team has added since I last logged in. Impressive.

Unfortunately, it didn't work, at least not for me. That's because I have much too strong an attachment to World of Warcraft. It's the ultimate high-engagement product. And yet, WoW never sends me emails. It doesn't notify me of anything, not even when my friends are logged in and about to start a raid. If I want to know what's going on, I have to log in and find out. It's up to me to decide when I want to do that. And how do I make that decision? Somewhere buried in my brain is a list, called something like "Things to do when you want to zone out and still have a feeling of accomplishment and power." At the top of that list is WoW. I'd only ever consider going to #2 on the list if #1 failed me completely. That's how most of us are - we only ever consider the #1 provider of any given service if it is available. Getting customers to see your service as #1 for a given category is what positioning is all about. (And manufacturing a new cateogry that you can be number one in is what resegmentation is all about)

In WoW's case, its positioning is established by the gameplay itself. WoW is a fun and addictive experience, and once it's sucked you in it's pretty hard to stop. But that is not the only source of positioning: brand advertisers have been using packaging and TV ads to do this for years. And most web applications do their positioning right in the first few screens of the app. This is why the registration is so important. At IMVU, we would routinely find retention effects that would stem from registration changes and have impact days or weeks later. One example I like to use is this: we added a YouTube video about IMVU to some landing pages. It was not prominently featured, but it did auto-play. We split-test that change, and watched the effects on engagement. Customers who saw the video were materially more likely to be active customers of IMVU ten days later.

The impact on behavior was pronounced, even though the immediate effect of the change was subtle. If I had to guess, I would say that if we had interviewed customers in the experimental group, they would not have been able to consciously recall the video they had seen during registration. But, unconsciously, it had affected the positioning of IMVU in their minds. Mission accomplished.


Anyway, for those of you planning on attending the Garage event, please come say hi. And for everyone else, please consider leaving your feedback - positive or negative - about the form or content of the presentation as a comment to this post. Your help is always greatly appreciated.

0 comments:

welcome to my blog. please write some comment about this article ^_^

Steak Diane Flambé

The hosts for March was Temperance of High on the Hog and Shawnee of Delishes Delishes. (The pictures through out this post are from Shawnee of Delishes Delishes, Mary of One Perfect Bite, and Debyi of Healthy Vegan Kitchen she did portabella steaks. ) Here is Temperance's post.

For this months challenge we decided to play with fire. My co-host Shawnee of Delishes Delishes came up with this recipe for us to try. As Shawnee said 'I've never purposely set fire to my food before (besides marshmallows)'. You know what, neither have I, about time wouldn't you say?

Steak Diane Flambé
recipe by Frank Bordoni from Great Food Live.
Ingredients
For the steaks
4x85g beef medallions
1 tsp Dijon mustard
freshly ground salt and pepper

For the sauce
1 tsp Butter, clarified
1 tsp Worcestershire sauce
2 tbsp Shallots, finely chopped
50g button mushrooms, finely sliced
1 tbsp lemon juice
125ml double cream
1 tbsp Chives, snipped
50ml Brandy

Method
1. Rub the medallions of beef with the mustard, season with salt and pepper and set aside.
2. Heat a large frying pan over a medium heat and when hot, add the clarified butter and Worcestershire sauce.
3. Add the shallots and mushrooms, and push to the centre of the pan. Arrange the medallions around the edge. Cook for 2 minutes, stirring and tossing the mushroom mixture as you go. If you prefer your steak well done, give it an extra minute or 2.
4. Add the lemon juice and season with salt and pepper.
5. Turn the steaks over and pour in the cream and chives. Tilt the pan slightly (away from you) and pour in the brandy at the far end. Now turn up the heat to high so that the brandy ignites. Swirl the sauce around in the pan and turn off the heat.
6. Put the medallions on 4 plates, pour over the sauce and serve.

Disclaimer:
We do not require that you flambé, if you choose to flambé and burn down your kitchen, don't sue us. If you choose to flambé try and get a picture (I recommend getting someone to help). Remember when playing with fire keep a fire extinguisher close and never use water on a cooking fire.

Here are some links to help, an Online Conversion Calculator , and a Guide to Flambéing.

From the Forum:
I completed this month's challenge and everyone loved it! I wasn't too crazy about the cream sauce, but everyone else did so that's all that matters
JMom of Cooked From the Heart

My boy loved the taste of the sauce.
Olga of Las Recetas de Olga

The recipe is very easy and everyone (all 6 of us) enjoyed it very much. The mushrooms I flambe'd were wonderful. Don't know how much I attribute to the flambe and how much to my mad cooking skills! But they were carmelized and yummy.
Shawnee of Delishes Delishes

0 comments:

welcome to my blog. please write some comment about this article ^_^

Venture Hacks interview: "What is the minimum viable product?"

I recently say down with Venture Hacks for an interview. Part one is up on their site today, in text, audio and slide format. Here are some topics and excerpts of what we covered, edited lightly for how I wish I'd said it at the time. To hear full audio and a complete transcript, click through to Venture Hacks.

Is "release early, release often" enough?

The issue there is, if you just follow the release early, release often mantra, you find yourself running around in circles, because you ship code, you get some feedback from people, you do a focus group.

Customers say,”Give me feature X,” “Give me feature Y,” and sometimes you do what they want, maybe sometimes you’re going to do what you want, and then they get mad at you. Pretty soon you’re chasing your own tail a little bit because you’re not operating against a clear, long-term vision of what you’re trying to accomplish.

The idea of minimum viable product is useful because you can basically say: our vision is to build a product that solves this core problem for customers and we think that for the people who are early adopters for this kind of solution, they will be the most forgiving. And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go.

So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.

Solving the chicken-and-egg platform problem

Developers don’t want to develop unless there are customers who are there to buy their products, and customers don’t want to come on the platform unless developers are there selling them something useful.

What we did is we took early adopter developers and we told them a story about how IMVU was going to take over the world and be this really powerful product for mainstream customers ... and we gave them an economic incentive that said, the earlier you get on board with the platform, the bigger your take is going to be for derivative products that get created down the road.

We shipped a product that had almost no customers — certainly no mainstream customers — but, because we had told that story effectively and we really understood those early adopter developers, we got a ton of them on the platform developing. They felt like they were in the middle of a gold rush, despite the fact that there was really no evidence to support that belief yet.

Starting with just a landing page

What we should have done, and what we did for a lot of features thereafter, is started with a landing page that promised people that product. Then we should have taken out the AdWords we were planning to take out, drive traffic to that landing page, and offer people to buy the experience that we are talking about.

What we would have found out if we were doing that experiment is 0% of people would have clicked through, which means it doesn’t matter what is on the second page.

The first page is so bad, not because it is badly designed, but because the features are wrong that you don’t need to go through the effort of building out the product. So we wished we had done that, and we did make that mistake really

Overcoming the fear of the false negative

As long as you’re not afraid of the false negative, that is, if you don’t get discouraged because you’ve built your first paper prototype of it and shown it to people and nobody wanted it. That can’t mean that like you give up because,”Oh, forget it, we’ll never make it.” You’ve got to say, "OK, well then let’s iterate some more.”

If you keep iterating at it, you keep making it a little bit more sophisticated, at a certain point after you’ve been through 10 iterations, that you still got no uptake whatsoever, and the feedback you’re getting from customers is still a yawn, you might say to yourself,”You know what? We’re not moving in the right direction. In fact, we’re past the point of minimum viable product. This just isn’t a viable product.”

Read the rest of the interview at Venture Hacks.

Reblog this post [with Zemanta]

0 comments:

welcome to my blog. please write some comment about this article ^_^

How to build companies that matter (the lean startup on O'Reilly Radar)

I have a post up today on O'Reilly Radar about using lean startup principles to build companies that matter. I have been wanting to respond to Tim O'Reilly's "build stuff that matters" concept for some time, and I'm delighted to have the chance to do it on Radar. Here's an excerpt:

Read the stories of successful startups and, if the founders are willing to be honest, you will see this pattern over and over again. They started out as digital cash for PDAs, but evolved into online payments for eBay. They started building BASIC interpreters, but evolved into the world's largest operating systems monopoly. They were shocked to discover their online games company was actually a photo-sharing site.

Each of these companies were fortunate to have enough time, resources, and patience to endure the multiple iterations it took to find a successful product and market. The premise of the lean startup is simple: if we can reduce the time between these major iterations, we can increase the odds of success.

And here's where working on something that matters to you more than money is critical. When you're committed to something larger than yourself, every minute counts. Hype and transient success won't keep you going. But the simple process of finding out whether or not your vision is right will. Because people who are dedicated to the truth are more likely to fail fast, learn, and try again.

Read the rest...

I'm working hard trying to figure out how to bring the lean startup message to different audiences. I think the O'Reilly audience is particularly important, as so many entrepreneurs got their start in technology (as I did) from their worn-down copy of Programming Perl. So if you're a reader of this blog and also of Radar, what kinds of information from this blog would you want to see explained over there? What concepts, techniques, or stories do you think will resonate? Please drop a note in the comments if you have a few minutes to spare. Thanks!

0 comments:

welcome to my blog. please write some comment about this article ^_^

Join the Lean Startup discussion at Web 2.0 Expo for free

I'm honored to announce that my Lean Startup session at the Web 2.0 Expo has been selected as one of a few "hybrid sessions" for Web2Open, the expo unconference. What does this mean for you? Two important things:
  1. Those of you at the Expo will be able to join in an open discussion session immediately following my talk on April 1st.
  2. Everyone else can register to come to both sessions for free, including the Lean Startup talk in the main conference.
I'm excited that we'll get more than the usual few minutes of Q&A, so come with a healthy appetite for conversation.

You heard me right. You - yes, you - can enjoy a full 90 minutes of Lean Startup discussion plus all of the other cool sessions offered by the unconference, entirely for free. Plus your Web2Open pass will "give you access to Web2Open, Hybrid Sessions, Keynotes, Sponsored Sessions, the Expo Hall, and BoFs." To sign up, simply register for for the conference and use the code websf09opn during registration. If you're planning to register for the full conference (which includes Web2Open for free) and would like a discount, you can use the discount code websf09fsd. Check out a full schedule of the Web2Open unconference here.

Last, I know some people have written in with feedback (and in surveys) that they'd like to be able to come to events like this but cannot afford to make the trip. Especially in times like these, it's nice to be able to help out. If you or your company is interested in sponsoring someone with a scholarship to travel to the expo and contribute to the conversation, please leave a comment or let me know. Similarly, if you'd like to be able to come but cannot for financial reasons, please drop me a line. I'll do my best to match deserving people up with appropriate sponsors, and I'll be glad to recognize those that give on the blog and at the conference itself.

Thanks, and looking forward to a healthy dialogue. Bring your questions (or post them as comments). See you April Fool's Day (no pranks, please).

Web 2.0 Expo San Francisco 2008


Reblog this post [with Zemanta]

0 comments:

welcome to my blog. please write some comment about this article ^_^

Combining agile development with customer development

Today I read an excellent blog post that I just had to share. Jim Murphy is a long-time agile practitioner in startups. He's often felt that there was something missing. In most agile development systems, there is a notion of the "product backlog" a prioritized list of what software is most valuable to be developed next. The breakthrough idea of agile is that software should be built iteratively, with the pieces that customers value most created first. This is a significant improvement on the traditional waterfall methodology.

But startups sometimes have trouble applying agile successfully. Or, rather, they apply it successfully, but things don't turn out so well. Enter Jim's post...
Customer Development - The Missing Piece!

But, over the years I’ve realized that the toughest problem - the one that matters most and was consistently the most challenging - was figuring out what the product backlog should be.

The backlog is the answer to the question: “What is the most important work we should do right now?” it presumes that you could confidently make that list, and keep it up to date as things change - or at least articulate what you’re building and for whom. Embedded in that assumption is why startups fail. How do you really make the best backlog for your company?

XP and Scrum don’t have much to say - they punt. Its by far the hardest part of the puzzle of shipping successful products and both recommend that you get a customer in the room and ask them to clarify what they want as you go. Well, that’s fine as far as it goes but when you’re a startup and you don’t have customers yet you need a way to bootstrap and that can feel awfully chaotic and wasteful. What’s worse is that as you grow you’ve probably developed some pretty bad habits as far as setting priorities and strategy: like thinking you’re a genius - just because you got funded - and that genius is what allows you to *know* what the market wants.

I remember having this exact same "aha!" moment, auditing Steve Blank's class when we were first building IMVU. Ever since that time, I have struggled to explain how the feedback loop in customer development should interface with the feedback loop in product development.

If you look at the origins of most agile systems, including Scrum and XP, they come out of experiences in big companies. Consider the classic project that was essential to the creation of extreme programming, the Chrysler Comprehensive Compensation System. This was to be a new piece of software to run payroll for Chrysler. In a project like that there are lots of big questions that need to be answered in order to build a working product. But you don't generally have to ask "what problem are we trying to solve?" That's pretty clear. In the case of C3, that was to run payroll for 87,000 employees, who were presumably receiving payroll before the project began. What causes projects like this to fail in traditional software development is that the solution is unknown. Agile is one way to succeed, because pursuing unknowns iteratively is a good way to mitigate risk. What do you do if the problem itself is unknown?

In a startup, rather than think of ourselves as having a marketing department and an engineering department, I now believe it's better to think of ourselves as focusing our energies on unknown problems and unknown solutions. Approaching each of them iteratively is the right thing to do. But the biggest payoff of all can be found when we combine them into one large company-wide feedback loop.

Last year, I found myself back in Steve Blank's class at Haas, this time trying to teach the students about what it's like running engineering alongside customer development. Working with Steve, I came up with schematic diagrams that I hope illustrate this point. (You can see the full deck in my post on Customer Development Engineering or listen to audio from a more recent lecture)

I thought given Jim's prompting it might be useful to post this excerpt. Notice that the unit of progress changes as we move from waterfall to agile to the lean startup. For more on this latter point and why it's so important, consider taking a look at the posts Achieving a failure and Throwing away working code.




Anyway, thanks Jim for the great post. And credit once again goes to Nivi from Venture Hacks for sharing it with me.

0 comments:

welcome to my blog. please write some comment about this article ^_^

Almost Time

Well, there have been a lot of developments around these parts. Next month at this time, we'll be reporting some really big news--little love turns three and itty bitty love will be on its way (if not here already!)

This last trimester hasn't been without it's trials, though. Namely, the ruptured achilles tendon on my husband's left foot. He ruptured it on Valentine's Day playing basketball--moments before I said OUT LOUD to a friend, who is also pregnant, "It just occurred to me...our husband's could get really hurt playing this game!"

Fortunately, my mom had made a surprise visit that weekend, so she was able to look after the little one while Pete and I whittled our time away in the ER. He had surgery on February 23 and just got his cast off Monday. He won't be walking for another couple of months, though we're hoping for a "slow limp" in about one and a half.

Needless to say, I've neglected plenty, like this blog, for instance. And sparkling clean floors, which really bugs me since the nesting urge is in full effect. Oh, and all the letter writing and phone calling that I'd planned to do before the baby came.

A good friend suggested we take out an insurance policy with the next pregnancy, since I broke several bones in my hand and wrist with number one and now Pete and his injury with number two. Hmmm...

At any rate, I hope you all are well. I'll try to post some pictures soon of our current state--crutches, pregnant, runny noses and all.

Spring is coming!

0 comments:

welcome to my blog. please write some comment about this article ^_^

Don't launch

Here's a common question I get from startups, especially in the early stages: when should we launch? My answer is almost always the same: don't.

First off, what does it mean to launch? Generally, we conflate two unrelated concepts into the term, which is important to clarify right up front.
  1. Announce a new product, start its PR campaign, and engage in buzz marketing activities. (Marketing launch)
  2. Make a new product available to customers in the general public. (Product launch)
In today's world, there is no reason you have to do these two things at the same time. In fact, in most situations it's a bad idea for startups to synchronize these events.

Launching is a tactic, not a strategy. In the right situation, it's a very useful tactic, too. In particular, a marketing launch can help you do three things (courtesy, as is most of my marketing advice, of The Four Steps to the Epiphany):
  1. Drive customers into your sales pipeline. This is the usual reason given for a marketing launch, but for most early stage startups, it's a failure. That's because a marketing launch is a one-time event, and rarely translates into renewable audiences. Worse, if you are not geared up to make the best use of those customers when the launch sends them your way, it's a pretty big waste. And, as we'll talk about in a moment, you don't get a second chance.

    Because this reason is so often used as an excuse, I recommend giving it extra scrutiny. Are you really choosing to engage in marketing in places where your potential customers pay attention? Do your customers really read TechCrunch? If not, do not launch there. Even if you must launch to your customers, avoid the urge to also launch in extra places, just because your PR firm can do it at the same time.

  2. Establish credibility with potential partners. In some businesses, especially in certain industries like traditional enterprise software, you simply cannot bring a new product to market on your own. You need to combine your product with others, and this requires partners like OEM's or system integrators. A marketing launch can help you get in the door with those partners, if you're having trouble getting their attention. Again, it's critical to focus your marketing launch on those publications, venues, and channels that your potential partners are paying attention to. If you don't know who the partners are, what they pay attention to, or what kind of message they are open to receiving - it's too early to launch. Do some Customer Development instead.

  3. Help you raise money. If you are having trouble raising money, sometimes a little PR can help. But don't be too sure. When VC's and other investors see PR activity, they are going to expect to see significant traction as a result. If you launch and see only mediocre results, it may actually make it harder to raise money. Sometimes, it can be easier to raise money pre-launch, if the launch is not imminent and there is some fear on the part of investors that they might lose the deal when the launch drives awareness of your company to all their peers.
Those are the potential goals of a marketing launch, but those are not its only effects. It also has causes other tectonic shifts that many startups don't consider:
  1. A marketing launch establishes your positioning. If you don't know what the right positioning is for your company, do not launch. Figuring this out takes time, and few entrepreneurs have the patience to wait it out, because the business plan does such a good job of explaining what customers are going to think. The problem is that customers don't read your business plan.

    When you launch with the wrong positioning, you have to spend extra effort and money later cleaning it up. For example, we did some early press (in Wired, no less) for IMVU that called us the next generation of IM and compared us positively to AOL. At the time, we thought that was great. Now, I look back and cringe. Being compared to AOL isn't so great these days, and IM is considered a pretty weak form of socializing. When we finally launched for real, we had to compensate for that early blunder.

    Of course, we didn't realize it was a blunder at all. We were actually really proud of the positive coverage. In fact, at that time we were auditing Steve Blank's class at Haas, since he was an early investor. Since we hadn't shown him much in the way of progress recently, we actually brought in the article to show off. I won't recount what happened next (although your can hear us recount it in audio). Suffice to say I can trace my understanding of what it means to launch to that day. We're lucky we had a mentor on board who could call us on the bad strategy before it was too late. Most startups aren't so fortunate.

  2. You have to know your business model. Most startups launch before they've figured out what business they're in. Pay attention to your fundamental driver of growth. If the product needs to be tweaked just a little bit in order to convert users into customers, you want to figure that out before the launch. If the viral coefficient is 0.9, keep iterating until it's 1.1 before you launch. And if your product doesn't retain customers, what's the point of driving a bunch of them to use it? Spend your time with renewable sources of customers and iterate.

  3. You never get a second chance to launch. Unlike a lot of other startup activities, PR is not one where you can try it, iterate, learn, and try again. It's a one-way event, so you'd better get it right. Remember the story about IMVU's early encounter with Wired? When we finally did launch the company, even though our product had grown and changed significantly, Wired didn't cover it.
I wrote a little bit about the epic launch we had at a previous startup in my post Achieving a failure. We really did it well, with a great PR firm and great coverage. New York Times, Wall Street Journal, CNN, the works. But it turned into a crushing defeat, because we couldn't capitalize on all that attention. The product didn't convert well enough, the mainstream customers we were driving weren't ready for the concept, and the event fed expectations about how successful the product was going to be that turned out to be hyper-inflated.

Worse, we tricked ourselves into thinking that what the press said about our success was actually true. And even worse, we'd cranked up the burn rate in order to be ready to handle all those millions of mainstream customers we anticipated. When they failed to materialize, the company was in big trouble.

Why do startups synchronize marketing launch and product launch? I think it has mostly to do with psychology.
  1. Investors push for it. Many investors have a desire to see their companies lauded publicly. This actually makes a lot of sense, if you see the world from their point of view. Third-party validation is one of the few forms of feedback they have available to them. Most investors in startups have a 3, 5 or even 10 year horizon for liquidity. That means they don't really know if they made a good investment for a very long time. Seeing the press talk about what a great investor they are is a great form of feedback. As a bonus, it gives them something to show their partners and LP's.

    This trend is so strong, this is actually a question I recommend to screen potential investors: "How do you know it's time to launch the company?" See if their answer is about tactics or strategy.

  2. Founders push for it. Who doesn't want to see their name in print? Investors aren't the only ones with ego invested in the company. In some ways, founders are even worse. How do they know they are making progress? They spend so much of their time trying to convince everyone around them that their idea is great and the company is doing well: employees, investors, partners, friends, family, significant others - it's a long list. But when they go to sleep at night, who's there to convince them that they are making progress? My experience is that many founders actually have a deep anxiety that maybe they are not succeeding. Sure, they are keeping everyone busy, but are they really working on the right things? A marketing launch is a temporary salve for these kinds of worries. Plus, it gives you something you can send home to mom (hi, mom!). Unfortunately, it's not a long-term solution, so it can become a bit of an addiction and, therefore, a huge distraction.

  3. There is also fear of the accidental launch. Companies that are thinking strategically sometimes reason like this: "if we do a product launch, members of the public will see our early product. They'll form their own opinions, maybe see our wrong positioning, and maybe talk to members of the press. By the time we're ready for a marketing launch, it will be too late. Better to launch now and get ahead of the story, or stay in closed beta until we're ready."

    In most situations, this fear is misplaced. Here was our experience at IMVU, which I have seen replicated at many other consumer internet startups. We did alienate and mis-position to our early customers. Luckily, if your product isn't good enough to have traction, you simply cannot alienate very many customers - because you can't get them engaged with the product. When you finally do get traction, the millions who see the right positioning will dwarf the few who saw the wrong one. And you can get an astronomical amount of traction before anyone will write about your company of their own accord. IMVU was a top-1000 website in the world, with millions of customers and making millions of dollars without getting any significant press coverage.

    In fact, we often felt frustrated when new startups with a fraction of our success got terrific write-ups in Silicon Valley-centric venues. We had to resist the urge to launch just to make that frustration stop. And, more often than not, we'd watch those companies flame out and die while we continued to grow steadily every month. If we'd wasted energy chasing their PR coverage, we'd probably have died too.
So don't combine your product launch with a marketing launch. Instead, do your product launch first. Don't chicken out and do a closed beta; get real customers in through real renewable channels. Start with a five-dollar-a-day SEM campaign. Iterate as fast and for as long as you can. Don't scale. Don't marketing launch.

How do you know you're ready for marketing launch?
  • When you have a strategy for the launch, which means knowing why you're doing it. Make sure it's solving a problem you actually have, and not one that you think you might have some day.

  • Know what the success metrics are for the launch. If you know what the strategy is, you'll know how to tell it was a success. Write it down ahead of time, and hold yourself accountable for hitting those objectives.

  • Know what your fundamental driver of growth is. Make sure the math for your model makes sense. That way, you'll be able to predict the future. When customers come in from your marketing launch, you'll know exactly what they are going to do and how that benefits your business.

  • Know where, when, and how to launch. If you know what your strategy is, and you know your target well (customers, partners, investors) you will also know where they are paying attention, and what messages they are able to absorb. Hold yourself and your PR agency accountable for developing a high level of understanding of these questions ahead of time.
One last suggestions. Think about the psychological motivations that are driving you to want to launch earlier than makes sense for your company. See if there's anything you can do to address those underlying needs that does make sense. For example, if your employees are feeling frustrated that they don't get much third-party validation for their work, use a board of advisers to fill that role. Bring in people that they (and you) respect to evaluate your progress and make suggestions. In my experience, this has provided an effective boost to morale and also helpful guidance.

When you're ready, enjoy the launch. Until then, resist the urge.

0 comments:

welcome to my blog. please write some comment about this article ^_^

LESSON 49: FEEDING BEES

http://www.honeybeesonline.com/
Call us at: 217-427-2678

Hello from Long Lane Honey Bee Farms, a family beekeeping operation of my wife and family, David & Sheri Burns. In today's lesson, I want to teach on feeding bees especially during late winter and early spring. Before I do, let me share a few personal thoughts with you. Our family spent last weekend in Chicago along with our oldest daughter and son-n-law and our granddaughter. My oldest son held down hive production while we were away. Our family works hard, and these occasional get-aways keep us going.

I was on TV again promoting beekeeping. You can watch the three and a half minute video by
clicking here.

My wife and I have a passion for promoting beekeeping. We love it, enjoy it, and find it the perfect match for a family business. As we spend so much time teaching beekeeping classes, posting lessons online and talking to prospective beekeepers one on one, we realize that not everyone will make their beekeeping purchase from us. Even though most people who take advantage of all our free information do purchase equipment and bees from us, we also realize that some people will learn all they can from us but purchase their equipment and bees from some place else. But let me just say that when you do purchase from us you are supporting our efforts to promote beekeeping. Your support gives us the ability to continue to offer our FREE online beekeeping lessons and conduct our endless experiments and sustain our small business in these tough economical times. We appreciate your loyal support and business!

Support from our satisfied customers is what we count on! So thank you for recommending Long Lane Honey Bee Farms to your friends and among your bee clubs.

BUY YOUR BEES FROM US NOW!! DON'T WAIT! AND BE SURE TO GET YOUR HIVE EQUIPMENT, PACKAGE BEES AND NUCS FROM US SOON TOO!! You can call us Monday - Thurs from 10am- 4pm Central Time; fri 9-12pm. If you reach our answering machine, it means we are on the other line or that we stepped out. Leave you name and phone number and we'll return your call.
 
LESSON 48: FEEDING BEES


Nov-March is the time of the year when bees start running out of stored honey. To help them not die from starvation, it's important to feed your bees. If your bees die with their heads stuck in cells, they starved.

Winter-Bee-Kind For Winter Feed For Bees
In The summer of 2011 we introduced our Winter-Bee-Kind after several years of studying overwintering hives. We could barely keep up with production they were in such demand. We still make them right here at Long Lane Honey Bee Farms but we've expanded our production methods to keep up with demand. So many beekeepers told us that these were the only thing that got their hives through the winter. This year, it's time for the 2014 production year. We even mix the sugar and pollen and right here and pour the candy into the Winter-Bee-Kinds. WHAT IS A WINTER-BEE-KIND? It is a one piece candy board that provides food, ventilation, upper insulation and an upper exit/entrance to help bees remain healthier during the winter. Someone said it insulates, ventilates and feed-i-lates. With the built in upper vent, you don't have to worry about snow covering up your hive's lower entrance. The bees can still go in and out through the top vent spacing. We avoid shipping Winter-Bee-Kinds in hot weather and start shipping each September-March. You can place our Winter-Bee-Kinds on your hive anytime, even in the winter. Because it goes on top of the hive in place of the inner cover, and you are NOT removing any frames, it can be placed on the hive in cold weather. Just do it fast. Open the top, remove the inner cover and place the candy side down and the vent slot toward the front of the hive and you're done. Click here to order your Winter-Bee-Kinds Some form of a candy board has been around for a long time. Beekeepers of long ago placed candy in their hives to provide enough food for their bees to survive the long months of winter. There are various mixtures and receipts for candy boards. Some are made with soft candy and some with hard candy. The end result is still the same. The bees will consume the sugar as they need it. We've always been concerned about the amount of condensation that can develop in the hive during the winter. The bees produce heat within their hive and as the temperature is very cold outside the hive, condensation will develop on the warm side, just above the bees on the inner cover or top cover. This condensation can accumulate and drop down onto the winter cluster of bees below. Bees can stay warm in the winter but they must remain dry. If this cold water drips down onto the bees, it can reduce their ability to keep their cluster warm. The insulation on our Winter-Bee-Kind helps reduce the excessive moisture and even puts some of that moisture to work, as it accumulates on the candy and makes it easy for the bees to consume the sugar. Thus, a Winter-Bee-Kind can help lessen two winter stresses, the lack of food and excessive moisture. We make our Winter-Bee-Kinds with sugar and a healthy amount of pollen powder. Many beekeepers make the mistake of only feeding their bees sugar in the winter, but the bees also need protein which they obtain from pollen. Our Winter-Bee-Kinds come with pollen mixed in with the sugar.. Click here to order your Winter-Bee-Kind today. We recommend that you place candy boards on your hive any time between Oct-March.


Commonly Asked Questions
Q: Which way does the candy face in the hive?
A: The candy faces down just above the winter cluster. Normally, this means that the Winter-Bee-Kind would be placed on the brood box that contains the cluster. For example, if you overwinter your bees in a single deep hive body, the Winter-Bee-Kind would be placed on this deep hive body with the candy facing down toward the cluster. If you are using two deep hive bodies to overwinter, then the Winter-Bee-Kind would be placed on the top deep hive body. It is best to disregard the use of an inner cover, and simply place your top cover over the Winter-Bee-Kind.

Q: What about winter moisture?
A: Moisture can develop in the winter from condensation, a contrast of the heat the bees produce in the hive and the extreme cold temperature outside the hive. Condensation accumulates on the warm side, which means moistures collects on the inner cover or top cover above the hive. This can drip down on the bees and chill them during the winter. A Winter-Bee-Kind takes the place of an inner cover and any moisture that develops from condensation aids the bees in consuming the candy.

Q: How long will a Winter-Bee-Kind last on a hive?
A: On average about 3 weeks. However, a colony that has ample stored honey may not consume the candy board as fast or not at all until they need it. A colony close to starvation may consume a Winter-Bee-Kind within a week or two.

Q: Since Winter-Bee-Kinds are placed or replaced on the hive in the winter, can I open the hive up on a cold day?
A: It is best to place the candy boards on a hive when the temperature is above freezing and try to place the candy board on and have the hive sealed back up within 1-2 minutes. It should not take over 1 minute. Do not remove any frames in cold temperatures, only place your Winter-Bee-Kind on and off quickly. If you can choose the warmest day during the winter, that would be best. Try to avoid very cold, windy or rainy days.

Q: How do I refill a candy board?
A: It is best to send back your candy board and we will refill it for $7 plus shipping. If you are a good candy maker, you can do it yourself.

Q: How do I get one with a pollen?
A: Our Winter-Bee-Kinds contain pollen as well.

Q: Can I make my own?
A: You can, but you must experiment, because you do not want the candy to be too hard or too runny. The exact mix depends on your altitude, heat source and other conditions so it will be different from one location to another.

Q: Why was some liquid sugar dripping out of my Winter-Bee-Kind when I received it?
A: It is the nature of candy boards to be a bit on the dripping side even though the top may be hard. Do not be concerned if you see liquid sugar dripping out of your boards when you receive it. It usually means it was left on end during shipment for a prolong period of time. The bees will clean everything up and enjoy this soft liquid.

Q: How much sugar is in one Winter-Bee-Kind?
A: Approximately 5 pounds

Q: When do I put a Winter-Bee-Kind on my hive?
A: Any time! Nov, Dec, Jan, Feb are good months to place on the boards.

Q How often should I check my Winter-Bee-Kind?
A: Every three weeks, take a peek.

Q: Do you make Winter-Bee-Kind for 5 frame nucs or 8 frame hives?
A: Yes, check out our website to order, but carefully read the description to make sure you are ordering the correct size and type.

Q: Can the candy break loose from the board on the hive?
A: It rarely happens, but during extreme winter weather, the candy and separate from the board while on the hive. This is not a problem. The bees will continue to consume the sugar.

Q: When I place it on the hive, do I use my inner cover. Just how does it go on?
A: Winter-Bee-Kind takes the place of your inner cover. Simply place the Winter-Bee-Kind on the top of your upper hive body or super with the candy facing down, then place your top cover on top of the Winter-Bee-Kind. Be sure to use a rock or brick to make sure the wind does not blow your top cover off. There is overwhelming enthusiasm about our Winter-Bee-Kinds. Click here to order now.
 
That's all for now! Until next time remember to Bee-Have yourselves!

David & Sheri Burns



0 comments:

welcome to my blog. please write some comment about this article ^_^

Lo, my 2295 subscribers, who are you?

I've previously written about the advantages of having a pathetically small number of customers, and how to get started with customer segmentation. Since my subscriber count has doubled again (thanks!), it seemed time to return to the subject of investigating who my customers are. Today, I'd like to spend some time on two techniques: the problem presentation and learning what channels of information reach customers.

Let's start with what I learned last time. Thanks to those of you who were willing to fill out the survey, I learned my net promoter score (about 25) as well as some clear other segmentation insights: about 80% of you are founders of or work at a startup, you read many of the same other blogs, and many of you would like to engage with Lessons Learned in formats and venues beyond this blog.

Before I go any further, here's the link to the new survey. If you are willing, please take a moment to fill it out before proceeding with the rest of the post; it'll mean less biased results, and you'll have a better idea what I'm talking about later.

Click Here to take survey

As always, I like to start with the NPS question. If this was a startup, I'd be asking it of a sample of customers even more often, because getting a regular tracking result is helpful for informing your decision loop. As I've written before, it is often a leading indicator of major problems. Another key benefit is what it enables in terms of analyzing responses to the survey. For example, those of you who classify yourselves as promoters are more likely than average to have found out about Lessons Learned from another blog. People who joined from sites like Reddit are more likely to be detractors. That's not an earth-shattering insight, but segmenting answers gets more interesting as the quality of the questions we're asking improves. In the first survey, most of the questions were open-ended because I had no idea what kinds of answers to expect, or even if anyone would answer at all.

That's a common pattern to gaining customer insight. Start with open-ended, subjective inquiry, like talking to customers on the phone. As you begin to see patterns, turn to more quantitative options like structured surveys or split-tests to confirm those patterns without as much observation bias.

In the new survey, you'll find more structured questions. They are centered around two themes. The first is asking after problems that you're experiencing. The challenge with these sorts of questions is to keep them open-ended, and to read the answers carefully. Every product ultimately is satisfying a need in the customers who buy it or use it. Products that don't solve satisfy any need for any customers tend to die out quickly. The more painful curse for startups is the product that satisfies a need or solves a problem - but that problem is not very important.

For startups, it is critical that the problem you are trying to solve is top of mind for at least some customers. To see if you're on the right track, consider this hierarchy of customer pain, courtesy of the Four Steps to the Epiphany:
  1. Customer has a problem.
  2. Customer knows they have a problem.
  3. Customer knows they have a problem and is actively trying to solve it.
  4. Customer has a budget allocated to the problem or is otherwise trying to spend money solving it. Ideally, they are trying to spend money but can't find a vendor to solve it for them.
  5. Customer is actively spending money, time or effort on solving the problem and failing. This is likely to be an early adopter, because they have the vision to see that the problem is important and they are already putting together a solution out of piece parts. But if that piece-parts solution is great, then it's unlikely they are going to need to buy any additional products.
Because this language may lead you to believe this concept is for enterprise sales only, I thought I'd walk you through an example from the world of consumer electronics. One of my favorite gadgets at home is the Harmony Universal Remote. This device let's you control all your home entertainment devices without requiring you to "train" it from your existing remotes. It connects to the internet to automatically download the necessary codes. But the real breakthrough is a usability insight: that people don't really want to control devices. They want to do activities. So the remote has buttons for simple high-level activities like "watch TV" or "watch a movie." When pressed, the remote configures all the right settings automatically to fulfill the customer's intention. It works like magic.

Imagine what it must have been like for Harmony in their early days. Most customers they talked to have a problem: their coffee table is littered with tons of obscure remotes. Do they know they have a problem? Not in that many cases. Sure, people like to complain about their consumer electronics, but most people have way bigger problems in their lives. But there are some people who have this problem in a more severe form, and since we have the benefit of hindsight, we can quote them. Here's a representative view from an actual Amazon customer review:
We all know how to operate our own entertainment center, but what happens when you have to explain it to your babysitter, mother-in-law, or your wife? Before this remote, I had a Sony RM-AV3000. It was a decent remote, except that it took hours to set up the macros, and the instructions that I had to leave for the babysitter were longer than the instructions for my kid!
This remote took 15 minutes to set up 6 different components (including lighting) on Windows Vista. Long lasting battery, great feel, a little pricey but anything to make it easier on me. After all, a happy wife is a happy husband. A happy mother-in-law...is a happy? Well, I wouldn't go that far!
That's an example of someone who had a problem, knew they had a problem, and had previously tried to solve it with a complex and inadequate solution. If Harmony had sat down with this person in their early days and asked them about their "remote control situation" I am confident they would have heard an earful. And if they had sketched out the concept for the activity-based remote they were building, I'm pretty sure he would have signed up on the spot. That's an early adopter.

If you are grappling with understanding what problem your product solves, try building a "problem presentation." This is way of talking to potential customers in which you do not mention your product at all. If it's appropriate, build a few slides. Or create an online survey. Or just talk to people in person. However you do it, focus on explaining the problem you think you will eventually solve and how important it is. If your customer is nodding along, keep getting more and more detailed about how the problem affects their life or their company. When they look confused, stop and ask them to explain, clarify, and correct you. When you get to the point where you can get three consecutive customers to nod through your whole presentation, congratulations. You've got an accurate read on the problem. Then, and only then, should you proceed to start trying to sell people your solution.



The second set of questions in the survey are focused on learning where you currently go to find solutions. In particular, I've focused on the two channels of communication that were most commonly suggested in the first survey: conferences and books. In a startup, these channels of communication are critical to understand for advertising, launch and PR purposes. But beyond the obvious, it's also important to know where customers go to get answers to pressing questions. If they are willing to pay big bucks, for example, to attend a conference on a certain topic, that bodes well for your ability to sell them a product related to that topic. And, for conferences, it also tells you where to go to talk to them. This is especially important for startups that have a small number of target customers, like those that sell only to large companies in specific industries.

I'll mention one last thing about knowing what channels of communication your customers engage with. It also gives you insight into their language. This is important, especially if you are a very early stage company. If you're used to pitching your company in a startup hub, like here in Silicon Valley, you may suffer from a debilitating disease: the inability to describe your product to normal people. That's no big deal if all you want to do is sell to people who live in startup hubs. But for most of us, that's devastating.

For example, when pitching IMVU, I used to say things like: IMVU is an 3D avatar IM platform with a micropayment economy powered by user-generated content. No customers understood what that meant. If we had bothered to ask them where they get their information, none of them would have said TechCrunch or Mashable. If we had spent even a tiny amount of time engaging them on this question in our early days, we could have saved a lot of time. Of course, we would have had to spend some time reading teen magazines. But isn't that a small price to pay to change the odds of your startup making it?

So thank you so much for subscribing. And an extra thank you to those of you who can spare a few minutes more to let me know what you're thinking. Have suggestions for other questions to ask in future surveys? Go ahead and leave your thoughts in the comments.

0 comments:

welcome to my blog. please write some comment about this article ^_^

Employees should be masters of their own time

Every startup should have a culture of learning. That's easy to write, and I forgive anyone out there who thinks that is too much of a platitude to any meaning. I'm also skeptical of people who suggest "changing the culture" as a prescription to fix a company's problems, because that just begs the question of how company cultures change. Without entering into that theoretical domain, in this post I'd like to try and offer a specific and concrete suggestion for how to build a culture of learning into a startup.

The suggestion is that you implement one single company-wide rule. The rule is simple: every employee is 100% responsible for how they spend their time. If it sounds simplistic, let me try and make the case that it is actually quite radical.

For example, let's consider job descriptions. When I was a manager, I was once leading a cycle post-mortem. We were talking about what went right and wrong in the company's development process, when one (relatively new) employee said something like "I noticed that problem, but I couldn't do anything about it." I asked why. He obviously thought I was being dense, and told me "it's not in my job description." I asked, "how do you know what your job description is?" Now he really thought I was nuts, replying "from the recruiter who hired me, of course!"

It was my turn to be dumbfounded. Of course, we use job descriptions for recruiting, but it had never occurred to me that somebody would take them literally. But once I was confronted with the situation, it seemed obvious. What else was he supposed to go on? I realized that, although I personally believed in the policy of trusting employees to know what they are supposed to do, I hadn't taken the necessary actions to build that trust into the culture of the company. Oops.

So we instituted a new policy on job descriptions, which I would take pains to reinforce whenever I could find an appropriate segue. It was, simply, that every person in the company has this job description: in any situation it is your responsibility, using your best judgement, to do what you think is in the best interests of the company. That's it. Everything else is only marketing.

This is not an easy policy to implement. Most people think it can't possibly work; it sounds like a recipe for anarchy. But it's not. If you're hiring creative, resourceful and smart people (and you are screening for that, right?) you don't need to worry about them suddenly going off the reservation and deliberately harming the company. And if you're giving them all of the information they need to understand the company's strategy, customers, and processes, you can be confident that they'll be able to apply that understanding to their current responsibilities.

What's that you say? You're not currently doing all of those things? That's too bad, because if you don't keep your smartest people fully-informed, you're going to wind up telling them what to do. And telling knowledge workers what to do is one of the biggest causes of mistakes, waste, and general low morale that I've ever seen.

Taking this radical view thus leads directly to other important process improvements. In order to have everyone understand the company strategy, we opened up our board and board of advisors meetings to the whole company, not just a select few. In order to give people the data they need to apply the strategy, we were very open with our company metrics, making all reports generally available and easy to run. And we presented the full company P&L every month, as soon as we got it from our controller. And it requires a formal process for on-boarding new employees (including root cause analysis when it goes wrong) to make sure everyone understands their job description and what it means day-to-day.

If you've never engaged in radical transparency before, you may be anticipating problems already. What about when you have to present bad news, doesn't that impair morale? Board meetings are frenetic, doesn't that lead to confusion about what the plan is or who's in charge? Those are valid concerns, and I've had to cope with them and many more. But the coping is actually extremely useful. By forcing these issues out into the open, transparency teaches you what your employees are really thinking. Over time, your whole team will become much more aligned, and able to handle the inevitable curveballs that circumstance delivers. Mutual trust is a prerequisite for rapid response.

Let's return to my initial promise, that giving employees 100% responsibility for their own time will lead to a culture of learning. Part of the way it does that is by creating transparency. But it has a corresponding impact on employee responsibility.

This policy doesn't leave much room for excuses. Take a failed product launch. At IMVU, these were quite common (after all, we're shipping code 50 times a day). Lots of those features would turn out to be a bad idea. I expected a certain amount of grumbling, since nobody likes a failure. But I didn't have any patience for one particular complaint: "I knew it wasn't going to work!" There is no room for this idea in a company that insists that every employee owns their own time. If you know something isn't going to work, it's your 100% responsibility to speak up and prevent it from happening. That may lead to a lot of arguments, but that's what you want. When smart people clash over prediction of the future, two critical things happen:
  1. They are forced to make their predictions specific. This is a prerequisite for institutional learning. When you think a certain feature will give a 50% boost to a given metric, and it only eeks out a 5% boost, you can't spin that as failure. But if you weren't specific about the goal, 5% can be rationalized as success.

  2. People share their assumptions and prior thinking. Often arguments result in one side being convinced, because the other side has real data to support their conclusion. Other times, it will be revealed that one party or the other is making empty assertions, or relying on credentials. You want those situations to be painful.
Over time, a team that feels this level of responsibility gets used to using data to justify their decisions. What other basis is there for achieving reliable consensus? And it really cuts down in interdepartmental warfare, because everyone is considered qualified to understand the arguments used to justify decisions. In a level playing field, people's true expertise becomes evident. If your marketing team actually uses data to make decisions, your engineering team will be impressed. And if not, at least now you know and can do something about it.

I honestly don't know how startups survive without this sense of responsibility on the part of the people doing the actual work that affects customers. It's just so easy to check out, follow the plan, and not rock the boat. That may make it easier to get everyone to follow the plan, but I also think it makes it much more likely that you'll achieve a failure instead.

No, I do not mean masters of their own domain. Don't even go there.

Reblog this post [with Zemanta]

0 comments:

welcome to my blog. please write some comment about this article ^_^