There are three legs to the lean startup concept: agile product development, low-cost (fast to market) platforms, and rapid-iteration customer development. When I have the opportunity to meet startups, they usually have one of these aspects down, and need help with one or two of the others. The most common need is becoming more customer-centric. They need to incorporate customer feedback into the product development and business planning process. I usually recommend two things: try to get the whole team to start talking to customers ("just go meet a few") and get them to use split-testing in their feature release process ("try it, you'll like it").

However, that can't be the end of the story. If all we do is mechanically embrace these tactics, we can wind up with a disaster. Here are two specific ways it can go horribly wrong. Both are related to a common brain defect we engineers and entrepreneurs seem to be especially prone to. I call it "if some is good, more is better" and it can cause us to swing wildly from one extreme of belief to another.

What's needed is a disciplined methodology for understanding the needs of customers and how they combine to form a viable business model. In this post, I'll discuss two particular examples, but for a full treatment, I recommend Steve Blank's The Four Steps to the Epiphany.

---

Let's start with the "do whatever customers say, no matter what" problem. I'll borrow this example from randomwalker's journal - Lessons from the failure of Livejournal: when NOT to listen to your users.

The opportunity was just mind-bogglingly huge. But none of that happened. The site hung on to its design philosophy of being an island cut off from the rest of the Web, and paid the price. ... The site is now a sad footnote in the history of Social Networking Services. How did they do it? By listening to their users.

randomwalker identifies four specific ways in which LJ's listening caused them problems, and they are all variations on a theme: listening to the wrong users. The early adopters of LiveJournal didn't want to see the site become mainstream, and the team didn't find a way to stand up for their business or vision.

I remember having this problem when I first got the "listening to customers" religion. I felt we should just talk to as many customers as possible, and do whatever they say. But that is a bad idea. It confuses the tactic, which is listening, with the strategy, which is learning. Talking to customers is important because it helps us deal in facts about the world as it is today. If we're going to build a product, we need to have a sense of who will use it. If we're going to change a features, we need to know how our existing customers will react. If we're working on positioning for our product, we need to know what is in the mind of our prospects today.

If your team is struggling with customer feedback, you may find this mantra helpful. Seek out a synthesis that incorporates both the feedback you are hearing plus your own vision. Any path that leaves out one aspect or the other is probably wrong. Have faith that this synthesis is greater than the sum of its parts. If you can't find a synthesis position that works for your customers and for your business, it either means you're not trying hard enough or your business is in trouble. Figure out which one it is, have a heart-to-heart with your team, and make some serious changes.

---

Especially for us introverted engineering types, there is one major drawback to talking to customers: it's messy. Customers are living breathing complex people, with their own drama and issues. When they talk to you, it can be overwhelming to sort through all that irrelevant data to capture the nuggets of wisdom that are key to learning. In a perfect world, we'd all have the courage and stamina to perservere, and implement a complete Ideas-Code-Data rapid learning loop. But in reality, we sometimes fall back on inadequate shortcuts. One of those is an over-emphasis on split-testing.

Split-testing provides objective facts about our product and customers, and this has strong appeal to the science-oriented among us. But the thing to remember about split-testing is that it is always retrospective - it can only give you facts about the past. Split-testing is completely useless in telling you what to do next. Now, to make good decisions, it's helpful to have historical data about what has and hasn't worked in the past. If you take it too far, though, you can lose the creative spark that is also key to learning.

For example, I have often fallen into the trap of wanting to optimize the heck out of one single variable in our business. One time, I became completely enamored with Influence: The Psychology of Persuasion (which is a great book, but that's for another post). I managed to convince myself that the solution to all of our company's problems were contained in that book, and that if we just faithfully executed a marketing campaign around the principles therein, we'd solve everything. I convinced a team to give this a try, and they did tried dozens of split-test experiments, each around a different principle or combination of principles. We tried and tried to boost our conversion numbers, each time analyzing what worked and what didn't, and iterating. We were excited by each new discovery, and each iteration we managed to move the conversion needle a little bit more. Here was the problem: the total impact we were having was miniscule. It turns out that we were not really addressing the core problem (which had nothing to do with persuasion). So although we felt we were making progress, and even though we were moving numbers on a spreadsheet, it was all for nothing. Only when someone hit me over the head and said "this isn't working, let's try a radically new direction" did I realize what had happened. We'd forgotten to use the all the tools in our toolbox, and lost sight of our overarching goal.

It's important to be open to hearing new ideas, especially when the ideas you're working on are split-testing poorly. That's not to say you should give up right away, but always take a moment to step back and ask yourself if your current path is making progress. It might be time to reshuffle the deck and try again.

Just don't forget to subject the radical new idea to split-testing too. It might be even worse than what you're doing right now.

---

So, both split-testing and customer feedback have their drawbacks. What can you do about it? There are a few ideas I have found generally helpful:

• Identify where the "learning block" is. For example, think of the phases of the synthesis framework: collecting feedback, processing and understanding it, choosing a new course of action. If you're not getting the results you want, probably it's because one of those phases is blocked. For example, I've had the opportunity to work with a brilliant product person who had an incredible talent at rationalization. Once he got the "customer feedback" religion, I noticed this pattern: "Guys! I've just conducted three customer focus groups, and, incredibly, the customers really want us to build the feature I've been telling you about for a month." No matter what the input, he'd come around to the same conclusion as before.
  
  Or maybe you have someone on your team that's just not processing: "Customers say they want X, so that's what we're building." Each new customer that walks in the door wants a different X, so we keep changing direction.
  
  Or consider my favorite of all: the "we have no choice but to stay the course" pessimist. For this person, there's always some reason why what we're learning about customers can't help. We're doomed! For example, we simply cannot make the changes we need because we've already promised something to partners. Or the press. Or to some passionate customers. Or to our team. Whoever it is, we just can't go back on our promise, it'd be too painful. So we have to roll the dice with what we're working on now, even if we all agree it's not our best shot at success.
  
  Wherever the blockage is happening, by identifying it you can work on fixing it.
  
  
• Focus on "minimum feature set" whenever processing feedback. It's all too easy to put together a spec that contains every feature that every customer has ever asked for. That's not a challenge. The hard part is to figure out the fewest possible features that could possibly accomplish your company's goals. If you ever have the opportunity to remove a feature without impacting the customer experience or business metrics - do it. If you need help determining what features are truly essential, pay special attention to the Customer Validation phase of Customer Development.
  
  
• Consider whether the company is experiencing a phase-change that might make what's made you successful in the past obsolete. The most famous of these phase-change theories is Crossing the Chasm, which gives very clear guidance about what to do in a situation where you can't seem to make any more progress with the early-adopter customers you have. That's a good time to change course. One possibility: try segmenting your customers into a few archetypes, and see if any of those sounds more promising than another. Even if one archetype currently dominates your customer base, would it be more promising to pursue a different one?
  

As much as we try to incorporate scientific product development into our work, the fact remains that business is not a science. I think Drucker said it best. It's pretty easy to deliver results in the short term or the long term. It's pretty easy to optimize our business to serve one of employees, customers or shareholders. But it's incredibly hard to balance the needs of all three stakeholders over both the short and long-term time horizon. That's what business is designed to do. By learning to find a synthesis between our customers and our vision, we can make a meaningful contribution to that goal.
Read More »

...there are thousands of plugins available. Here's a short list of 11 that are handy. It might also remind you to look for others:11 top wordpress pluginsSee also:4 WordPress Tips for Surviving Slashdot, Digg, Reddit or StumbleUpon
Read More »

Life is not easy when you're working in an old-fashioned waterfall development process, no matter what role you play. But I have a special sympathy for the "product manager" in a startup that is bringing a new product to a new market, and doing their work in large batches. I met one recently that is working on a really innovative product, and the stories I heard from their development team made me want to cringe. The product manager was clearly struggling to get results from the rest of the team. These are smart people trying hard to all row in the same direction. So why are they having so much difficulty?

Let's start with what the product manager does. He's supposed to be the person who specifies what the product will do. He writes detailed specs which lay out exactly what features the team should build in its next iteration. These specs are handed to a designer, who builds layouts and mockups of all the salient points. Then the designs are handed to a team of programmers with various specialties. Each specialist takes up his part of the spec (UI, middleware, backend) and cranks out code. Last, the QA team builds a test plan based on the spec, and then tests the features to make sure they conform to the plan.

This system naturally lends itself to a pipeline approach, which the product manager organizes. While the programmers are off building the next major feature, he is busy writing specs so that, when they finish, there won't be any idle time before they can start the next iteration. If the programmers go idle, it's bad news for the product manager, because he's supposed to keep them busy building product. Otherwise, the company is wasting serious money.

When I met this team, some acrimony had built up. The last few features came out pretty different from what was origianlly spec'd, and took far too long, to boot. The programmers keep asking for more say in the designs and direction that they work on. So the team has been spending more and more time in the spec and design phases, trying to get team buy-in on what they are going to build. For some reason, though, despite the increased buy-in, the final product often doesn't look anything like the original spec. The VP Engineering spends all of his time trying to make sure the programmers understand and implement the spec. Each iteration takes longer than the previous one. Frustration is mounting.

It doesn't take long to discover that the product manager is being forced to write every spec five times. First, he writes it nice and clear. Next he works with the designer to build out the design spec, and with QA to build out the test plan. When the programmers get it, they often start negotiating with him about what's going to be built. They exchange countless emails, and he's being constantly interrupted and being asked to clarify exactly what the spec means. The fourth spec exists only in these emails, which are changing the design in an ad-hoc fashion. By the time QA gets the feature, their test plan is badly out of date. So the product manager winds up actually having to use the software, by hand, updating the spec and helping create a new test plan. Naturally, the deviations from the spec are so severe, that he has to rewrite the spec he's currently working on (for the next major feature) to take them into account.

Ironically, this system was designed to keep each functional group 100% utilized, so nobody goes idle, including the product manager. But as the iterations get longer, he's spending more and more of his time answering questions. The interruptions are so bad, he has to write his new specs at 3AM, just to keep the pipeline full.

What's wrong with this picture? Everyone is working at 110%, with full dedication. But the team is falling further and further behind.

Here are the changes I'm working with this team to implement

• Work in cross-functional teams. Each team has a representative of each function. To start, we'll try a product manager, designer, programmer or two, and QA. The team owns a complete feature end-to-end.
  
• Focus on speed of iteration rather than utilization of every function. Let people go idle, if they can't help the current iteration succeed. I'm contiuously amazed how many people have untapped creativity and resourcefulness. They don't want to be idle. By letting them focus on the success of their team exclusively, you empower them to do whatever it takes to make the team successful. Will that mean someone in design will jump in to help QA get the release certified? We'll see.
• Switch the spec process from push to pull. Start with a one-page spec, no more. Then, let the team ask questions of the product manager whenever they need clarification. In exchange, the team agrees to show each piece of working code to the product manager for his approval. They'll find points of disagreement much faster, and resolve them in realtime. Plus, the team will get better and better at interpreting the concise specs that only have to be written once. (Eventually, they may abolish specs altogether)

There's much more this team can do to eliminate waste in the way that they work and thereby iterate faster. Eventually, I hope to get them on a full agile diet, with TDD, scrums, sprints, pair programming, and more. But first I think we need to save the product manager from that special form of torture only a waterfall product development team can create. Once the different parts of the team can trust each other again, we'll have the basis we need to start a true continuous improvement feedback loop.
Read More »

(Update February, 2011: This post originally dates from October, 2008 back when I first started writing this blog. I've updated the "official" conference bio below but otherwise the text remains unchanged from that original essay.)

The most common feedback I've heard from readers has been that I should provide details on my background. I didn't include much on the blog at first, because I want you to judge what I write based on what I say, rather than who I am. So if you're new, consider not paying any attention to the rest of this post, and just diving into the archives, if you haven't already. (Maybe you'd like to start with The lean startup, How to listen to customers, or What does a startup CTO actually do?)

For everyone else, here's the standard bio paragraph I use for conferences and other formal occasions:

Eric Ries is the creator of the Lean Startup methodology and the author of the popular entrepreneurship blog Startup Lessons Learned. He previously co-founded and served as Chief Technology Officer of IMVU. In 2007, BusinessWeek named Ries one of the Best Young Entrepreneurs of Tech and in 2009 he was honored with a TechFellow award in the category of Engineering Leadership. He serves on the advisory board of a number of technology startups, and has worked as a consultant to a number of startups, companies, and venture capital firms. In 2010, he became an Entrepreneur-in-Residence at Harvard Business School.

He is the co-author of several books including The Black Art of Java Game Programming (Waite Group Press, 1996). While an undergraduate at Yale Unviersity, he co-founded Catalyst Recruiting. Although Catalyst folded with the dot-com crash, Ries continued his entrepreneurial career as a Senior Software Engineer at There.com, leading efforts in agile software development and user-generated content. 

I'm one of those people who's been programming since they can remember. I got my start programming on an old IBM XT; it was thanks to MUDs that I first discovered the internet. Those early text-based games were programmed by their own users, and it was by far the best tutorial I could ever have received in the power of software. In a MUD, you could literally conjure new objects that never existed before, just by programming them. I know many people who think that software works like magic, but to me it actually was magic.

Later, I discovered you could get paid to program computers, and really never looked back. While I was still in high school, I became a Java "expert" during a time when there was no such thing. Thanks to Sun's amazing PR blitz, there was tremendous demand for experts on Java, and I did my best to convince people that I was one of that mythical breed. Thanks to the anonymity of the internet, I landed a few jobs, and did quite a bit of writing.

By the time the entrepreneurial bug hit me, the dot-com boom was in its waning days. So much for timing. But I managed a few "good learning experiences" before throwing myself full-bore into IMVU. For almost five years I had the opportunity to build and serve with one of the most talented team I have ever seen. It was by far the most intense and most rewarding experience of my professional life. Because of IMVU's reputation, I've also had the opportunity to serve as an advisor or board member for more than a dozen startups. Rolling up my sleeves and serving with them has enriched my understanding and provided many of the lessons I write about here.

In retrospect, there are some clear themes that stand out from across my career. I have always tried to be a consistent advocate for rapid iterations, fact-based decision making, free software, and values-centric organizations. Every startup has a chance to change the world, by bringing not just a new product, but an entirely new institution into existence. That institution will touch many people in its life: customers, investors, employees, and everyone they touch as well. I believe we have an obligation to ensure the resulting impact is worthy of the energies we invest in bringing it to life.

Eventually, I came to summarize these themes with the phrase "the lean startup." Lean is one of the major trends shaping our world, and its impact goes beyond just optimizing our supply chains. Lean startups can be the most capital efficient companies in the world, because they strive to prevent energy from being expended uselessly. Human talent, passion, and wisdom is too precious a commodity to allow it to be wasted.

So that's me, your author. I hope you take something of value from this blog. If you do, please share your story here in a comment.

Thanks for stopping by.
Read More »

Scene: Dinner table, Ava is finished and has started to scratch her head.

Daddy: Do you have a scratch?

Ava: Yes, but I itched it back with all the other itches.

::

Cool, fall weather today. I think I'll make pumpkin bread.

::

Splurge-time:

A new container for my flour (1/2 the price at the store where you're only required to buy one).I was tired of only being able to fit a 1/2 cup scoop in the jar I had. Nothing that I bake ever requires just a 1/2 cup of flour, so I decided to make things a little bit easier.

Read More »

What does your Chief Technology Officer do all day? Often times, it seems like people are thinking it's synonymous with "that guy who gets paid to sit in the corner and think 'technical' deep thoughts" or "that guy who gets to swoop in a rearrange my project at the last minute on a whim." I've tried hard not to live up (or down?) to those stereotypes, but it's not easy. We lack a consistent and clear definition of the job.

When I've asked mentors of mine who have worked in big companies about the role of the CTO, they usually talk about the importance of being the external face of the company's technology platform; an evangelist to developers, customers, and employees. That's an important job, for sure, and I've been called upon to do it from time to time. But I don't think most startups really have a need for someone to do that on a full time basis.

So what does CTO mean, besides just "technical founder who really can't manage anyone?"

I always assumed I wouldn't manage anybody. Being a manager didn't sound fun - deep down, who really wants to be held accountable for other people's actions? I mean, have you seen other people? They might do anything! So I initially gravitated to the CTO title, and not VP of Engineering. I figured we'd bring in a professional to do the managing and scheduling-type stuff, and I could stay focused on making sure we built really awesome technology. But along the way, something strange happened. It became harder and harder to separate how the software is built from how the software is structured. If you're trying to design an architecture to maximize agility, how can that work if some people are working in TDD and others not? How can it work if some folks are pre-building and others use five why's to drive decisions? And what about if deployment takes forever? Some options can improve the performance of the softare at the expense of readability, deployability, or scalability. Should you take them? These sounded to me like technical problems, but when you do any kind of root cause analysis they turn out to be people problems. And there's really no way to tackle people problems from the sidelines.

So I wound up learning the discipline of managing other people. Turns out, I wasn't too bad at it, and I found out just how rewarding it can be. But since I spent a long time in a hybrid CTO/VP Engineering role, I still have this nagging question. Just what is the CTO supposed to do?

Here's my take. The CTO's primary job is to make sure the company's technology strategy serves its business strategy. If that sounds either too simple or too generic, think for a second if any companies you know do the reverse. Have you ever heard a technologist use technical mumbo-jumbo to make it sound like a business idea he or she didn't like was basically impossible? That's what we should be trying to avoid.

I'll try and break it down into five specific skills.

• Platform selection and technical design - if your business strategy is to create a low-burn, highly iterative lean startup, you'd better be using foundational tools that make that easy rather than hard. Massive proprietary databases? I don't think so. Can the company dig into its tools when they fail and fix them? If not, who's going to insist we switch to free and open source software? When projects are getting off the ground, who can the team check with to make sure their plans are viable? Who will hold them accountable for their project's impact on the platform as a whole?
  
  
• Seeing the big picture (in graphic detail) - the CTO should be the person in the room who can keep everything your technology can and can't do in their head. That means knowing what's written and what's not, what the architecture can and can't support, and how long it would take to build something new. That's more than just drawing architecture diagrams, though. Being able to see the macro and micro simultaneously is a hallmark of all of the really great technologists I've had the privilege to work with.
  
  
• Provide options - another mark of a good CTO is that they never say "that's impossible" or "we'd never do that." Instead, they find options and can communicate them to everyone in the company. If the CEO wants to completely change the product in order to serve a new customer segment, you need someone in the room who can digest the needs of the new (proposed) business, and lay out the costs of each possible approach. Some technologists have a tendency just to "decide for you" and give you the "best" option, but that's dangerous. You can't have an honest dialog if one party knows all the answers.
  
  
• Find the 80/20 - this was my favorite part of the job. Sometimes, you're in a meeting where someone wants to build a new feature. And in their mind, they've got it all spec'ed out. It slices, it dices, and probably washes your car too. In my mind, they're racking up costs (one month for that part, two months for that other part, uh oh). On a bad day, I'd just give them the sobering news. But a good day looked like this. Once I understood what the objective of their feature was for customers, I could sometimes see a way to get 80% of the benefit for 20% of the cost. "Would you be able to learn what you need to learn if that feature just sliced, but not diced? Because if we don't have to add a dicing module, we can repurpose the flux capacitor via solar flares...." I was constantly amazed how often the answer was something like "really? dicing is what's expensive?! I just threw that in there on a whim!"
  
  
• Grow technical leaders - I like to formalize this responsibility by eventually designating some engineers as "Technical Leads" and delegating to them the work of guiding the technical direction of more and more projects. This is the only way to scale. It also forced me to get clear about which aspects of our company's technical direction were really important principles, and which were just artifacts of how we got there. With multiple people trying to work to the same standard, we had to be a lot crisper in our definitions. Was the fact that we were primarily using PHP essential, or could we add new tools written in other languages? Was it an important or irrelevant fact that most of our web code was procedural and not object-oriented? What if someone wanted to write their module in OOP style? By delegating and training, we create a corps of leaders who could step in to provide CTO-like services on demand. And by working together, we created a team whose whole was greater than the sum of its parts.
  

I want to add one last idea, even though I recognize it is controversial, bordering on the boundary between the CTO and VP Engineering. I don't know how much I'm being influenced by having worn both hats, but I think it's important enough to go out on a limb and add.

• Own the development methodology - in a traditional product development setup, the VP Engineering or some other full-time manager would be responsible for making sure the engineers wrote adequate specs, interfaced well with QA, and also run the scheduling "trains" for releases. But I think in a lean startup, the development methodology is too important to be considered "just management." If the team is going to use TDD or JIT scalability, for example, these choices have enormous impact on what the architecture must look like. At a minimum, I think it's the CTO and Tech Leads that have to be responsible for five why's-style root cause analysis of defects. Otherwise, how can they find out what their blind spots are and make sure the team and the architecture is adjusting? That job calls for someone who sees the big picture.

Your CTO might be a great architect, evangelist, interface designer or incredible debugger. Those are great skills to have, and I'm curious what you've seen work and not work. I'll be the first to admit that my experience is limited, so I'm collecting anecdotes. Have you worked with or for a great CTO? What made them exceptional? What's one thing a brand-new first-time CTO could learn from them?
Read More »

Ava informed me that it was time to write Santa a letter. "No," she thought, "let's call him instead."

I explained to her that he responded best to letters and that if he took phone calls he'd never get anything made.

Curious, I asked, "What do you want to say in your letter to Santa?"

"I want him to bring me a pink guitar and a shirt with a pocket at Christmas."

::

Containing the Splurge (and a bit of the urge)

We've been cleaning out around here. Sorting, tossing, and containing. While we've been trying to use what we have, we needed a little bit extra, too. So we bought some storage containers, like these, from the container store. (Careful though, shipping can get expensive).
Read More »

"TED U talk on pitching to a venture capitalist tells you the 10 things you need to know about yourself -- and prove to a VC -- before you fire up your slideshow":
Read More »

One of my favorite things about having a blog is the feedback I get in comments and by email. Today, I thought I'd answer a few questions that came in from a very thoughtful comment from Andrew Meyer. (He's also a blogger, at Inquiries Into Alignment).

Question 1:

When you're adding features to a product used by an existing user base, do you still do split testing to determine usage patterns?

Absolutely, yes. Sometimes, testing with existing customers is more complicated than with new customers. Existing customers already have an expectation about how your product works, and it's important to take this into consideration when adding or changing features. For example, it's almost always the case that a new layout or UI will confuse some customers, even if it's a lot better than the old one. You have to be prepared for that effect, so it doesn't discourage you prematurely. If you're worried it, either run the test against new customers or run it for longer than usual. We usually would give changes like this a few extra days to see if customers eventually recover their enthusiasm for the product.

On the other hand, existing customers can be a testing benefit. For example, let's say you are adding a new feature in response to customer feedback. Here, you expect that customers will find the feature a logical or natural extension, and so they should immediately gravitate to it. If they don't, it probably means you misunderstood their feedback. I have made this mistake many times. At IMVU, for example, we used to hear the feedback that people wanted to "try IMVU by themselves" before inviting their friends to use it. Because many on our team came from a games background, we just assumed this meant they were asking for a "single-player mode" where they could dress their avatar and try controlling it on their own.

Turns out, shipping that feature didn't make much impact when we looked at the data. Turns out, what customers really meant was "let me use IMVU with somebody I don't know" so they could get a feel for the social features of the product without incurring the social risk of recommending it to their friend. Luckily, the metrics helped us figure out the difference.

Question 2:

If your product has areas where people read and then different areas where people interact, are there ways to do metrics to determine where people spend their time? Could this be done on mouse focus, commenting amounts, answer percentages, download percentages, etc?

There are ways to measure customer behavior in tremendous detail, and in some situations these metrics are important. But lately I have been recommending in stronger and stronger terms that we not get too caught up in detailed metrics, especially when we are split-testing. Let's run a thought experiment. Imagine you have incredibly precise metrics about every minute that every customer spends with your product, every mouse click, movement - everything. So you do a split-test, and you discover that Feature X causes people to spend 20% more time on a given part of your product, say a particular web page.

Is that a success? I would argue that you really don't know. It might be that the extra time they are spending their is awesome, because they are highly engaged, watching a video or reading comments. Or it could be that they are endlessly pecking through menus, totally confused about what to do next. Either way, you would have been better off focusing your split-test on high level metrics that measure how much customers like your product as a whole. Revenue is always my preferred measure, but you can use anything that is important to your business: retention, activation, viral invites, or even customer satisfaction in the form of something like net promoter score. If an optimization has an effect at the micro level that doesn't translate into the macro level - who cares?

For more on the details of how to do simple and repeatable split-testing, take a look at The one line split-test, or how to A/B all the time.

Read More »

Today, I want to offer another lesson in beekeeping focusing on how to prepare our hives to make it through the winter. Before I get into today’s lesson, let me remind you that we do have our beekeeping class coming up October 11th here at our apiary. If you are interested, we might be able to squeeze in a couple more people, so give us a call at the number at the bottom of this lesson. Also, we are still producing queens, though it is getting late in the year, now is still a good time to requeen.
By the way, here at Long Lane Honey Bee Farms, we are a family business working hard to help more people discover and enjoy keeping honey bees. We manufacture beehives and sell everything related to beekeeping. Our busiest season is from November-July. So if you are planning on purchasing hives from us, and you don’t mind getting them early before next year, then now would help relieve the spring demand and we always raise our prices the first of January.

We have a reputation, a particular way of keeping bees. Here are a few fundamentals about beekeeping that we have settled on and have become known for:
1. No harsh chemicals. (We do not use any chemicals in our hives)
2. Use locally produced queens. (We raise and sell from our own survival stock).
3. Screen bottom board.
4. Hive inspection every 2 weeks, especially for monitoring the queen.
5. Yearly requeening is a must!
I was not very fond of requeening yearly until this summer. I did a little test. I requeened about half of my hives and the other half I allowed the 2-3 year old queens to carry on. Each half consisted of approximately 25 hives. By far, hands down the requeened hives way out performed the hives with the older queens. It was not even close. The hives with the older queens had lower population of bees, weaker foraging power, less honey, less everything.

I immediately became a firm believer of requeening a hive every year. September proves to be the most strategic month so that the queen is laying strong going into and coming out of winter, and the new queen can lay well in the fall to produce lots of young bees who should overwinter better than older bees.

Okay, so those are a handful of our particular philosophy of beekeeping.

Now, let’s talk about getting your hives ready for another winter. What should you do? Winter is a nervous time for beekeepers. With every snow, and blast of cold, north wind, we wonder and worry how our bees are doing. Months of cold, winds, snow, rain, fog and clouds causes us to fret over our bees well-being.

In December, most of us place our ear against the outside of the hive and give a gentle tap to see if they are still buzzing, and usually they are. It is rare for a hive to die in December or even in January. The fact is, most hives that die do not even die in February. They die in March, when they have exhausted their food supply and have few to forage the early nectar on the occasional warm days.

So what can we do to help our bees make it through winter? There is no plan that ensure 100% survival. Bees are livestock. Things can just go bad. But a few things can help.

Typically, most consider winter preparations consists of the following:
1) Put on a mouse guard at the entrance.
2) Lift the hive and see if it has enough stored honey by how heavy it is.
3) Wrap the hive with some sort of insulation or roofing paper.
4) We build a wind break.
5) We treat for mites and nosema.

These might be good measures to take. However, they are not fail proof. In fact, here are three concerns that probably cause our hives to die during the winter that many overlook:

1) Queenlessness. Your hive is most certain to die if your queen is weak or gone going into winter.
2) Winter Condensation. If you seal up your hive too tight, you might increase the overall condensation within the hive and cause this cold water to constantly drip onto the cluster and eventually kill your hive.
3) Keeping stored honey next to the winter cluster. How many times do we hear that a hive died even though there was plenty of honey.

So, here’s my checklist for what you should be doing to your hives now to prepare for a great hive in the spring:

1) Remove queen excluders.
2) Remove honey supers.
3) Examine the amount of stored honey and be sure your bees have plenty. Most beekeepers in the north lift the back of the hive and hope it feels like there is 70 pounds of stored honey. 70 pounds is the approximate equivalent of 1 medium super full of honey.
4) If your hive is short on stored honey, FEED! Feed 2:1 sugar water. Use an internal or top feeder if robbing is a problem. Robbing is more of a problem during the fall dearth.
5) Make sure that your hive has some sort of upper ventilation. It does not have to be much but something. We now make our inner covers with ventilation slots. And we leave our screen bottom boards open all winter.
6) Use good mouse guards, either metal or wooden entrance cleats to keep mice out.
7) Treat the hives 3 weeks in a row with powdered sugar for mite control. This is best started in August.
8) If wrapping hives, be sure to allow upper ventilation.
9) Combine weak hives with strong ones. Most of the small swarms you caught are not going to winter well unless you caught them in May. Do not feel like a failure if you’ve worked hard to build up your numbers, but now you have to slice your hive count in half by combining hives. Combining ten hives into 5 which survive the winter is better than having 8 out of 10 die out.

Much can be said about preparing a hive for winter, but the hive that has the best chance of surviving the winter will be the hive that was very strong all year and has a young queen. Remember, a strong hive is more apt to be pest and disease free, thus overwintering much better because it does not have viruses caused by mites.

No matter how much you wrap your hive, medicate your bees and build a wind break, nothing will do much to improve a weak hive overwintering well. Only strong hives overwinter well enough to explode in the spring. Weak hives that do survive the winter usually are not impressive the following year, unless requeened soon in the spring.

This year, I will expand my overwintering experiments. I will be overwintering a variety of configurations to see which hive does best. I will be overwintering 5 frame nucs, single hive bodies and a hive that is made up of 1 deep hive body and 3 medium super boxes.

We also have one hive going into winter that we are now feeding pollen and heavy nectar to stimulate the queen to keep laying deep into fall to see if this is better or worse of winter survival.

Please put it on your calendar to peak in your hive in January on a decent day when the temperature rises to atleast 40 degrees. Then, make a plan to quickly open your hive on a calm day and in 1 minute or less, pull up a frame of honey, scratch it open and place it next to the cluster. If they have no honey left, then feed!

I have a lesson that explains several feeding methods. The lesson can be found at:http://basicbeekeeping.blogspot.com/2008/03/lesson-28-spring-management-of.html

I hope this lesson will motivate you to take advantage of the last few weeks of decent weather and tighten up your hives, feed them and make sure they are ready for winter. We are excited about the 2009 beekeeping year. The crises of the decline in honey bees is still with us. Last year, we helped so many jump into beekeeping for the first time. This is exciting to us because bees play such an important role in our food supply.

2009 = 1,000

For 2009 we have set a goal of encouraging 1,000 people to become first time beekeepers. We will be putting up a special web page with a goal chart anonymously reflecting each new beekeeper.

We only want to count those who we have directly inspired to keep bees for the first time. So here's the criteria for you to be counted as one of the 1,000:

1) Educated by us through our online lessons or you attended one of our on site classes as a new beekeeper.

2) Bought wooden ware or package bees from us as a new beekeeper.

3) Our website introduced you and encouraged you to start keeping bees.

Our website with our goal chart will be a frame from a hive showing 1,000 cells. Every time another person becomes a 1st time beekeeper we will seal off that cell. Eventually we hope to see all 1,000 cells completely sealed off, as all beekeepers know the joy of seeing a complete frame of sealed brood! So, get the word out. Our next blog post will reveal more of the details and the website to watch the goal expand. So get the word out, and help us reach this very lofty goal.

Sheri and I would like to thank you again for being a part of our lives, and enjoying the great experience of keeping bees. Have a great day and we'll see you soon!

Remember, BEE-have yourselves!

David & Sheri Burns

Long Lane Honey Bee Farms

217-427-2678

www.honeybeesonline.com

Read More »

I'm going to be talking about lean startups (and the IMVU case in particular) three times in the next two weeks at Stanford. It's exciting to see the theory and methodology being discussed in an academic context. The entrepreneurship progarms of the business, engineering, and undergraduate schools are all tackling the subject this semester, and I'm honored to be part of it. Even better, my friend Mike Maples, one of the pioneers of microcap investing in startups, is teaching a unit in Stanford's E145 on "The New Era of Lean Startups."

It's a real challenge to communicate honestly in these classes. I struggle to try and make the students actually experience how confusing and frustrating startup environments are. When we do the IMVU case, we generally get complete consensus in the class that several of the zany things we did are 100% right. Complete consensus? We didn't even think they were 100% right. And we still argue about whether our success came from those decisions, or some exogenous factor.

It's one of the hard things about learning just from hindsight, and it matters in the board room every bit as much as in the classroom. You can only learn from being wrong, but our brains are excellent rationalizers. When something works, it's too easy to invent a story about how that was your intention all along. If you don't make predictions ahead of time, there's no way to call you on it.

In fact, in the early days, when IMVU would experience unexpected surges of revenue or traffic, it was inevitable that every person in the company was convinced that their project was responsible. Those stories would be retold and repeated, and eventually achieved mythological status as "facts" that guided future action. But making decisions on the basis of myths is dangerous territory.

How did we combat this tendency? I don't pretend that we did it well. But many of the tools of lean startups are designed for just this purpose:

• Regular checking in with and regular talking to customers surfaces bogus theories pretty fast
  
• Split-tests make it harder to take credit for someone external factor making you successful
• Cross-functional teams tend to examine their assumptions harder and with more skepticism than purley single-function teams
• Working in small batches tends to make it less likely that you'll attribute big results to small changes (because the fact that small changes sometimes do lead to big results is counter-intuitive)
• Rapid iteration makes it easy to test and re-test your assumptions to give you many opportunities to drive out superstition
• Open source code invites criticism and active questioning
  

Still, it's hard to make the case that these solutions are needed, because the problems seem so obvious. I hear some variation of this pretty often: "I mean, sure those guys were rationalizing and kidding themselves. But our team would never do that, right? We'll just be more vigilant." Good luck.

Let me end with a challenge: see if you can find and kill just one myth in your development team. My suggestion: take a much-loved feature and split-test it with some new customers to see if it really makes a difference. If you try, share your story here. I'm especially interested in what you used to share the idea with your colleagues. What language should we use? What arugments are persuasive? What works and what doesn't?


Read More »

I can't remember what life was like before the internet. I mean, did I really use the library as my go-to resource for information? What if I needed to know what the most widely used vegetable was on a Sunday afternoon? (The onion, by the way). Would I actually have to wait until Monday morning to find out?

Not to mention all of chock-full-of inspiration blogs that are out there and the very talented people behind them. My geography has even improved with all of this globalization. I mean, I knew somebody lived in Provo, Utah...but who and what do they do?

But sometimes, the internet can be all too consuming...and after an unplanned but well-worth-it break from cyber-sucking, I'm here to say that detachment is exactly what the doctor ordered.

Don't get me wrong. I clung dearly to email and couldn't help myself from Google-ing "toddlers with temperatures" and other random inquiries, but I didn't read one single blog, didn't even update my own. And really, it was liberating.

Here's why, from where I sit.

I think that healthy access to healthy information can turn addictive, which makes it, well, not healthy. I think that it is productive when it pushes, when it prods, when it inspires, and enhances a life.

But it's unproductive when it turns into a stick that we measure our own life by.

Take me, for instance. Generally, I blog about the funny, every-day, sometimes boring things in life; rarely about the nothing-went-right days with extra mistakes on the side. In general, blogs are a digest of what's working in life--where we're excelling, learning, and experiencing some degree of success.

And that is great. I love to learn from others. I NEED to learn from others. I know I'm not alone in that.

But sometimes, I think it is easy to read others' digests of success and feel like an entire volume of loser. When that becomes the lens ("let's see what someone else is doing that I am not") then it's time to change our lens. I can't speak for men, but I think women, generally, suffer from the big comparison-sucking disorder. Maybe it's our bodies, our marriages, our success, our finances, our jobs, our children, our parenting, you name it--we do it and we pay for it.

So, what did I do with the time I didn't spend blogging or reading blogs?

• I rested. I actually put my feet up on several occasions and closed my eyes. It felt great.
• I prayed. I sat quietly and just prayed. I received lots of guidance that I might not have from a blog.
• I organized. Mostly activities to do with my daughter so that when she woke, we could get down to business and laugh.
• I cooked for my family. I even made my first pot-roast ever and it turned out really really good.

This detachment period was really good for me. I don't tend to fall into comparison traps (I've worked hard over the years to avoid them) but when I'm tired and overwhelmed with work, they're easy to fall into.

So, I'll try to be more regular on the site now that I'm "back"--that's assuming that you're not going to do a detachment period of your own. If you do, enjoy it! And hope you'll visit again when it's over.

Splurgin Sweet!

My mother in-law got me this cookbook. Little one and I have been trying to stick to an every-other-week or at minimum an every-month sampling of its recipes. The hard part is selecting which recipe to try (and staying out of the dough). We haven't been disappointed yet.

Read More »

I'm always excited to see someone else writing about lessons learned from their startup, and wanted to link today to Untitled - Startup Lessons Learned -- Take it with a grain of salt. Here's something I can relate to:

We used assembla for subversion, scrums, milestones, wikis, and for general organizational purposes. We had all the tools in place but we didn’t actually practice agile development. Scrum reports would come in once a month, nobody was actually responsible for anything ... No fancy tools needed here — it’s about the mentality, attention to detail, and the actions that foster agile development, not the tools & systems you set up in place to facilitate this.

It's a natural assumption that, in order to implement a new process, we need fancy new tools. This is generally false. And even when new tools are needed, my experience has been that you can only figure out what tools you need once you have done the relevant task by hand. It's another example of the refactoring principle in action.

My favorite instance of this is scheduling software. Now, there are some situations where scheduling needs to be incredibly complex, like when many teams are working on something that is heavily synchronized and where the consequences of failure are severe. But it's incredibly easy to fool yourself into thinking that, so it's worth being a little skeptical.

If you read Lean Thinking, you can enjoy numerous examples of companies that replaced multi-million dollar MRP systems with a simple white board. The lean manufacturing guys call this visual control and it's very powerful. When you make progress evident to everyone on the team, you allow for decentralized initiative, and foster a focus on team (rather than individual goals). If you've never worked in this way, you'd be surprised how many people can lend a hand in areas way out of their specialty, if given the opportunity. Most engineers are terrible visual designers, but if the designer on their team is struggling, maybe they can help out with an icon or two. And wait until you see a "non-technical" designer writing simple code to try and speed up a release.

In order for progress to be evident it has to be:

• Simple - everyone on the team has to understand what it means. A typical setup might be to have cards representing tasks (as in XP story cards) and have them move across a board from an "in progress" column to "complete." I usually recommend a three-part board, where the left column is where the scrum-style "product backlog" is maintained in priority order, the middle represents tasks in progress, and the right column is for tasks recently finished.
  
  
• Visible - the whole team has to be able to see the status, and not just when they are actively having a problem. A board posted in the same room as the team is best, because you can't help notice it when you come in. In continuous integration sytems, a single colored status webpage can work (it looks like this). But putting the status on a webpage only works if members of the team have a reason to check it all the time. For example, I recommend that you wire up your source control system to disallow checkins while any of your unit tests are failing. This has lots of benefits, but one strong one is that it causes everyone to check the status of the build all the time.
  
  
• Accurate - if you've ever been managed by task-tracking software, you'll relate to the feeling that you either have to spend ludicrous amounts of time posting updates or the information goes stale. It's exponentially more frustrating if some people on the team update their status religiously, and others don't. The more visible the status is, the more likely people will update it, but it's also important that updates be a natural part of your workflow.
  
  For example, I recommend a simple rule: each team member is allowed to have only one task "in progress" at any given time. This rule is easy to enforce; just look up at the board and count the cards in the "in progress" column. It's also a natural accuracy-enhancer, since when you want to work on a new task, you need to move your old task to complete. If the task is not complete, you force people to surface the issue quickly. (It also has the nice side-effect of driving down the batch size of work, but that's for another post)

This framework for making progress evident applies to more than just scheduling, of course. Acceptance tests can make the progress of your features evident, assuming they are simple enough for everyone to understand, visible to all, and accurately reflect the goals of your project. Cacti graphs can serve the same purpose for quality of service, and a good business dashboard can help with business goals.

In each case, though, think twice before you set up an elaborate automated system. I used to think a giant flat-panel screen that broadcast our company's key metrics would be what was required to get everyone to pay attention to them. I never tried it, but I recently got to meet a startup who did. The result: as soon as the novelty value wore off, nobody paid attention anymore. A much better solution, I think, would be to have each project leader be in charge of physically printing out a one-page report every week with the relevant stats for their project, and present it to the whole company. If they are going to be judged by the output of that report, you had better believe they are going to: 1) make sure it is accurate, 2) check it often, and 3) make their team understand it.

Read More »

Master of 500 Hats: Startup Metrics for Pirates (SeedCamp 2008, London)

This presentation should be required reading for anyone creating a startup with an online service component. The AARRR model (hence pirates, get it?) is an elegant way to model any service-oriented business:

1. Acquisition
2. Activation
3. Retention
4. Referral
   
5. Revenue

We used a very similar scheme at IMVU, although we weren't lucky enough to have started with this framework, and so had to derive a lot of it ourselves via trial and error. Dave's done a great job of articulating the key metrics you want to look at in each of these five areas, and I won't bother repeating them here (go read the presentation already). He also has a discussion of how your choice of business model determines which of these metric areas you want to focus on. That's where I'd like to pick up the discussion.

I think the salient question to ask about any business model is: what is the primary driver of growth? I break the answer to that question down into three engines:

1. Viral - this is the business model identified in the presentation as "Get Users." Here, the key metrics are Acquisition and Referral, combined into the now-famous viral coefficient. If the coefficient is > 1.0, you generally have a viral hit on your hands. You get increasing growth by optimizing the viral loop, and you get revenue as a side-effect, assuming you have even the most anemic monetization scheme baked into your product. The law of large numbers (of customers) says you can't help but make at least some money - your valuation is determined by how well you monetize the tidal wave of growth. Examples of this are well-known, and (in my definition) include any product that causes new customers to sign up as a necessary side-effect of existing customers' normal usage: Facebook, Myspace, AIM/ICQ, Hotmail, Paypal.
   
   
2. Paid - if your product monetizes customers better than your competitors, you have the opportunity to use your lifetime value advantage to drive growth. In this model, you take some fraction of the lifetime value of each customer and plow that back into paid acquisition through SEM, banner ads, PR, affiliates, etc. The spread between your LTV and blended CPA determines either your profitability or your rate of growth, and a high valuation depends on balancing these two factors. To the extent that you have good word-of-mouth, activation or retention, these factors tend to drive down your CPA or drive up your LTV, and so are nice bonuses. But because paid traffic is fundamentally a bidding war, it's important that you have a differentiated ability to monetize customers better than other people who are bidding for the same traffic. Otherwise, your CPA will get driven up close to or exceeding your LTV, and you can't grow profitably anymore. IMVU is in this business, as is Amazon, Netflix, Match.com, and CafePress.
   
   
3. Sticky - Dave calls this "Drive Usage" and I think it's the model that causes the greatest confusion. Because Activation is a key term in the Viral business model equation, and Retention is a key term in the Paid business model, it's easy to mix up this type of business with the other two. For example, you often hear eBay or Neopets described as having viral growth, but I don't think that's correct. What those sites have in common (despite their very different audiences) is that something is causing their customers to become addicted to their product, and so no matter how they acquire a new customer, they tend to keep them. This has led to exponential growth. For eBay, this is caused by the incredible network effects of their business (so-called demand-side increasing returns and supply-side increasing returns). For Neopets, it's simply a side-effect of their game-like product design. Either way, you can use any marketing channel that's available to bring in new customers, including word of traditional advertising, SEO, SEM - wherever you can find prospects who are going to find your product addicting. But it's not really viral growth, even when it's exponential. Again, looking at eBay - most buyers and sellers would be 100% happy with eBay if it already had a critical mass of people to bid or create auctions. Although many eBay fans love to tell their friends about it, they really don't have a need to bring them on board. As far as they are concerned, that's eBay's job. That's why eBay advertises on search engines, and Facebook doesn't.
   

In my opinion, every startup needs to "pick a major" among these three drivers of growth. It's simply too hard to focus on more than one. It's a choice that has to be made at the level of strategy; notice how similar the tactics are between them. All three probably make attempts at world-of-mouth marketing - it's just that for Viral, it's life-or-death. Similarly, it probably makes sense for everyone to take advantage of SEO (hey, it's nearly-free traffic). But a Viral company who is focused there is probably going out of business.

The difficulty is exacerbated by the fact that these models also cut across business functions. Sometimes we have the attitude that the Product Development team is the one responsible for Activation and Retention (hey, a great product would do that naturally) or that the Marketing team is responsible for Revenue and Referral (hey, go get me some money or free customers already). In reality, the key metrics for your growth drivers have to be jointly owned. They cannot be delegated, unlike the minor metrics, which can easily be owned by one part of the business, or even outsourced. For example, it's always nice to have someone constantly optimizing your SEM accounts, driving down your CPA. They might even occasionally make "optimizations" that improve CPA but negatively impact LTV (or vice versa). But if you were using the Paid driver of growth, you just outsourced your heart while it was still beating. Oops!

One last thought. Beware the new hire who has "extensive experience" in startups or big companies - using a different growth driver. Make sure you test to see if they are truly open minded, because otherwise you risk them banging their head against a wall, trying to use the tactics that worked so well in their previous company. Be-double-ware of the new hire who has "years of industry experience in multiple companies" all in a different growth driver. It's the rare person who truly understands not just what worked in the past but why.
Read More »

I enjoyed reading a post today from Laserlike (Mike Speiser), on Scientific product development.

By embracing a scientific approach to product development, not only will your business have a much higher probability of success, but it will also be a more fun and creative place to work. Nothing kills innovation like the fear of failure. And nothing leads to failure like a process that resembles astrology more than it does astronomy.

There are two concepts I want to delve into a little more. The first is his version of the Code/Data/Learn feedback loop.

He focuses on having a clear idea of the problem you are trying to solve, running experiments, and then: "Did the results of your test match what you expected? If not, kill the feature and start over." My experience is this kind of thinking can run into trouble. The two extremes our brains tend to swing to are either "I know it's right, just do it" or, if things don't go as planned, "screw it, just give up." The goal of iterative development is to give us guard rails so we don't veer off to either extreme. When an experiment doesn't go as planned, that's the time to learn. Why didn't reality conform to our expectations? Unpacking our assumptions usually leads to important insights that should be plowed into a next edition of the feature. You can't do science and be defensive at the same time. If the product people on your team think they have to get every experiment right on the first try, there's no chance you're going to iterate and learn. So don't just kill the feature - iterate. Only when you've tried everything you can think of, and you're not learning any more, is it time to bring out the axe. Keep split-testing, but keep this iron rule: if it doesn't change customer behavior, it's not a feature. Kill it.



A second idea is that less is more in product design:

A key tenet of the philosophy is that uncluttered products with fewer, better features are preferred to similar products with more features. I agree with the less is more product development approach, but for a different reason.

The reason I like less is more as an approach is that it allows for a more scientific approach to product development. By starting a new product off with as few features as possible (1?), you can be incredibly scientific. With 10 features in a single release, you may spend more time trying to figure out what is working and what isn’t working than it took to build the thing in the first place. As you incrementally experiment with your product, you can observe the impact of a particular feature one at a time and adjust accordingly.

This is a great articulation of the principle that working in small batches allows problems to become instantly localized. The smaller the unit of a release is, the more you can learn about it, because the number of variables that have changed is so few. It's worth doing this not just for features, but for any changes you make to your product. For example, trying to make server software more scalable. Our instinct is sometimes to do giant big-bang rewrites. These rarely work on the first try - usually small mistakes wind up blowing away all the benefit of the macro change. If we can find ways to break the change down into tiny pieces, we can find and revert the small mistakes as they are introduced.

When I've worked to get everyone to build in small batches, I would see this pattern in action. Lots of engineers are busy checking in and deploying their work. Someone has managed to convince themselves that they have to do their big architecture change in one fell swoop. So they work on their own branch for a while, and then try to check in their massive changeset. All day long, I keep noticing them "bouncing" their changes against production: constantly checking it in, realizing something's not right, and reverting. What's not right? First, the tests don't pass. Then it turns out theirs some integration problem because their long-lived branch diverged too much. Then, during deployment, the cluster immune system rejects the change... etc. Meanwhile, a dozen other engineers are getting annoyed, because this constant bouncing is making it harder for them to work (they can't deploy changes while tests or the cluster are in red-alert mode). When we think that working solo, on a branch, in large batches is more efficient, this is the kind of waste we forget about. Sure, we kept that one engineer busy while they toiled away on their own, but did that optmize the whole team's efforts?

Working in a scientific and iterative way is not about cold, calculating facts. On the contrary - creativity being constantly challenged by reality is beautiful. This is a point practitioners of science are always trying to make. My experience is that this way of working is liberating. We don't have to sit around and argue about who's opinion is correct. We can just blitz through new, creative ideas, testing to see what's real. Now that is fun.

Read More »

Our hosts for September were Heather of Randomosity and the Girl and Temperance of High on the Hog. (The pictures through out the post are from Judy of Culinary Escapades, Rayrena of I Love Happy Cows and Kat of A Good Appetite. Here is what Heather posted.

I have long been a fan of Chinese food and the recent Summer Olympics in Beijing have made me crave the delicious dishes even more. One dish that I have always loved to eat is dumplings. While I love dumplings at restaurants, I had never been able to make a decent looking or tasty dumpling at home. So my co-host, Temperance, and I thought this would be a perfect challenge for us in September.

Chinese dumpling or Jiaozi, generally consists of minced meat and chopped vegetables wrapped into a piece of dough. Popular meat fillings include ground pork, ground beef, ground chicken, shrimp, and even fish. Popular mixtures are pork with Chinese cabbage, lamb with spring onion, leeks with eggs, etc. Jiaozi are usually boiled or steamed. Jiaozi is a traditional dish for Chinese New Year's Eve. Family members gather together to make dumplings. (1)

The recipe we have chosen is simple but it allows for variation. If shrimp and turkey isn't your thing, pork and chicken are other options. Or you can go straight vegetable filling if you prefer. You can also pan fry the dumplings instead of steaming. I've tested the recipe both ways and each way is delicious.

Shrimp Dumplings
Prep Time: 20 min, Cook Time: 20 min, Makes 24

Dumplings
4 large shiitake mushrooms
3 scallions
1/2 garlic clove
8 ounces shrimp, peeled and deveined
6 ounces ground turkey
2 teaspoons soy sauce
1 teaspoon dark sesame oil
3 dashes of hot red-pepper sauce
24 dumpling wrappers (see recipe below)

Dipping Sauce
2 tablespoons soy sauce
2 teaspoons rice wine vinegar
1/2 teaspoon honey
1/2 teaspoon dark sesame oil
1/2 teaspoon minced fresh ginger or 1/8 teaspoon ground ginger

1. Coat a steamer basket with a non stick cooking spray and set aside. In a small saucepan, soak the mushrooms in boiling water to cover for 15 minutes, then drain. Remove and discard the stems; cut the caps into quarters.

2. In a food processor, combine the mushroom caps, scallions, and garlic and whirl until coarsely chopped. Add the shrimp and whirl until finely chopped. Transfer to a medium bowl and stir in the turkey, soy sauce, oil, and red-pepper sauce.

3. Place 1 tablespoon of the shrimp mixture in the center of each dumpling wrapper. Dampen the edges with water, the fold up the sides around the filling, pleating the edges. Place in the steamer basket, leaving 1/2 inch of space between the dumplings for the steam to circulate. Set over boiling water, cover, and steam for 15 minutes.

4. For the dipping sauce, in a small bowl, whisk together the soy sauce, vinegar, honey, oil, and ginger. Serve the dumplings hot with the dipping sauce.

Personalize it!
For a different flavor, use ground pork in place of the ground turkey. You can also drop a pinch of chopped scallions into the dipping sauce if you like

HOT WATER DOUGH:

4 cups all-purpose flour
1/2 teaspoon salt
1 1/2 to 1 3/4 cups boiling water

In a stainless steel bowl mix flour and salt. Slowly add hot water to flour in 1/4 cup increments. Mix with chopsticks until a ball is formed and the dough is not too hot to handle. On a floured surface, knead dough until it becomes a smooth, elastic ball. Place back in bowl and cover with a damp cloth. Allow to rest for at least 1 hour. Working on a floured surface with floured hands, roll out dough to form a long 'noodle', 1-inch in diameter. Cut 1/2-inch pieces and turn them over so the cut sides are facing up. Flatten with your palm and roll out thin using a rolling pin. The dumpling wrapper should end up about 3 inches in diameter. (2)

Source: Extraordinary Meals from Ordinary Ingredients, ©2007 The Reader's Digest Association, Inc.
(1) Wikipedia link for Dumplings
(2) Ming's Dumpling Recipe

Quotes From the Forum:

Although I do love the pre-packaged skins from Chao's... Less preparation and cooking time, more eating time! I am glad that I can say I tried it from scratch though, my yeye and mama L would be proud.
Jen of Delightful Delicacies

I subbed tofu for the shrimp and turkey, and they tasted great! I ate way too many of them, and was uncomfortably full for awhile, but they were worth it. Great pick!
Debyi of Healthy Vegan Kitchen

All and all these were quite a treat and easier than we expected. We made a little dim sum feast that night that also included chive pancakes and sesame beans.
Kat of A Good Appetite

Read More »

It's not always fun being small. When you have an infinitesimal number of customers, it can be embarrassing. Some might look at my tiny "5 readers" badge and laugh. But as long as your ego can take it, there are huge advantages to having a small number of customers.

Most importantly, you can get to know those few customers in a way that people with zillions of customers can't. You can talk to them on the phone. You can provide personalized support. You can find out what it would take for them to adopt your product, and then follow up a week later and see if they did. Same with finding out what it would take to get them to recommend your product to a friend. You can even meet the friend.

For companies in the early-adopter phase, you can play "the earlyvangelist game" whenever a customer turns out to be too mainstream for your product. Pick a similar product that they do use, and ask them "who was the first person you know who started using [social networking, mobile phones, plasma TV, instant messaging...]? can I talk to them?" If your subject is willing to answer, you can keep going, following the chain of early-adoption back to someone who is likely to want to early-adopt you.

That level of depth can help you build a strong mental picture of the people behind the numbers. It's enourmously helpful when you need to generate new ideas about what to do, or when you face a product problem you don't know how to solve.

(For example, we used to be baffled at IMVU by the significant minority of people who would download the software but never chat with anyone. It wasn't until we met a few of them in person that we realized that they were having plenty of fun dressing up their avatar and modeling clothes. They wanted to get their look just right before they showed it to anyone else - they would even pay money to do it. But all of our messaging and "helpful tutorials" were pushing them to chat way before they were ready. How annoying!)

And since I have a blog, I have a way to ask questions directly to you. If you have a minute, post your answers in a comment, or email me. Here's what I want to know:

1. First of all, the NPS question: On a scale of 1-10 (where 10 is most likely), how likely is it that you you would recommend this blog to a friend or colleague?
2. How did you hear about it?
3. What led you to become a subscriber, versus just reading an article and leaving like everybody else? (or, if you're not a subscriber, what would it take to convince you?)
   
4. What do you hope to see here in the future?

Thanks, you loyal few. I am grateful for your time and feedback.
Read More »

I have had the opportunity to meet a lot of iPhone-related companies lately. Many of them have really cool products shipping or about to be released, and I wholeheartedly agree with my friends at the iFund that the next generation of applications is going to be amazing.

I've also been playing around with the App Store. From a technical point of view, it's amazing. You just install app after app after app, and it just works. My home screen is a giant mess, because installing apps is just so much fun.

But from a customer experience point of view, I'm not yet sold. Figuring out which apps are going to be any good is almost impossible. Even with only a few months of development, third parties have crammed every single category in the store full of apps. Most of my time in the store is spent scrolling through endless lists. And what distinguishes a good app? I can't really tell. All I see is a name, an icon, a price, the developer's name, and a review star-rating. The reviews are all over the map. When I choose to read them, it seems totally random what I'll find. But even clicking through to see a screenshot and some reviews is incredibly time consuming, given the hundreds of apps in most categories. Most of the time, I have no idea if I'm going to like the app after I install it.

So how's a normal person to choose? I think this is a major challenge for companies that hope to build dominance in some category on the iPhone. Today, the fact that the store is open and has almost no barriers to entry is great for the companies I meet, because they can get their first versions in front of customers quickly, and start iterating fast. But if they are lucky enough to have success, the store is going to become a nightmare, because it will give all of their competitors easy access to their customers and an opportunity to compete with them on an even playing field. The app store is not set up to allow anyone to achieve a durable advantage.

Browsing the app store is an awful lot like shopping in a retail grocery store. You see row after row of tiny boxes, each vying for your attention. They can't present much information, unless you take the box off the shelf and look at it. They rely on impressions, branding and price to try and get you to do that. The store determines which products sit on which shelves, and which yours sits next to. Of course, for a few extra dollars, the right people can get their products on more shelves, or in premium locations, or in giant promotional stands.

Sound familiar? In a world where competition is based on brief looks in predefined categories, it's hard to just "build a better mousetrap" and hope for the best. This is what brand marketers and consumer packaged goods companies have been studying and refining for years: how to win the battle in your mind before you ever set foot in the store. Once you have come to think of Crest as the #1 toothpaste, and, more importantly, your toothpaste, it's unlikely you're going to pay attention to the other boxes on the shelf, no matter how shiny they are.

There are other models, in other distribution channels. On Facebook, viral distribution has proved decisive. Those companies who have learned to build apps that optimize the viral loop dominate in every category where they compete. Not many customers ever browse the app directory or search for specific apps - they don't have to, they find out about apps by being invited by a friend. If you sell an online service that solves a defined problem, you can compete in SEO or SEM. If your site is consistently ranked #1 for a given search term, you can make it very hard for someone else to compete for new customers. In other markets, he who controls the directory has the power, like Download.com in the world of windows shareware.

Word of mouth is a powerful force multiplier in all of these models. If everyone I know is using a specific product, in most markets that's a heavy influence. And in some markets it's decisive, because of well-known network effects (as happened with Microsoft, eBay, and many others). But if your product category doesn't have strong network effects, word of mouth alone is not usually enough to fend off a competitor who also has a quality product.

So what model will prevail on the iPhone? So far, I don't see any apps that have much in the way of viral distribution. Do any apps really cause my friends to sign up, as a natural side-effect of my using the app? I haven't found any yet. And I don't see much searching for apps going on. Do most people know what kind of app they want? And how can they tell the best app for a given search? For example, I did a search for "taxi" in the app store. I got 4 results, 3 free, one for $0.99. I downloaded and tried all four of them (because I had time to kill) - and I'm still not sure which one was the best. Back when I was staring at the search screen, it really was a crapshoot.

So unless someone cracks the code on one of these other models, I think we may revert to the retail model, where good positioning and good branding will win. When I'm scrolling through the endless list of games in that category, the icon that I've come to associate with "that company that makes amazing iPhone games" is going to get a disproportionate share of my attention. Does that mean existing brands have the advantage? I'm not sure. For a lot of brands, their iPhone products will run into the line-extension trap (see The 22 Immutable Laws of Marketing). That looked to me like what's happening with EA's iPhone offerings. So there is an opportunity to build new brands with attributes like "the most amazing mobile apps" but I think building a company around that strategy means really thinking through how to do it. Just bringing a good app to market isn't going to be enough.

So for those who are thinking of starting a new company to build iPhone apps, here's the question I would be pondering. After I've built my first successful app, and all kinds of competitors have copied me and have similar apps right next to mine in the store, how will I continue to get new customers? How will new customers know that my apps are superior?

Read More »