The Wizard of Oz Approach

Dear YC,

The product I’m building combines a variety of technologies like Hadoop and NLP, which I haven’t really worked with before. After an initial research phase where I learn and experiment, this technology would then have to be commercialized and added into my existing product.

Any suggestions on staying on track, time, and budget? How should I keep the project focused?

Sincerely,

Aspiring Fast Learner

Dear Aspiring Fast Learner,

We’re glad you asked, because startups with a greater technical investment upfront have extra challenges with staying focused on measurable progress.

Before you go too deeply down the path of Hadoop and NLP, one question to ask yourself is whether you have to build the hard technology parts of the company before you can test it with customers. Many YC companies have had luck with a “Wizard of Oz" approach. Here’s how it works.

Build a prototype of your product, but have a human do the things you planned to do with fancy algorithms. You can be the human, or you could find a friend to be the “Wizard of Oz" behind the curtain. When you go around and show the product to customers, they’ll assume it’s automated and you can see whether you’re building something that they find useful. If it is, you can always build the algorithms to replace the humans.

In some cases this isn’t possible. If it’s not, then ask yourself what is the minimum work you need to do to get to a product you can test with customers. For example, maybe you can make the algorithms work well for a narrow set of users, rather than solving the general case.

Once you know the minimum work, try to break it down into discrete steps, as many as possible. Your estimate of the time for the project will be more accurate if you evaluate each step and then add them up, rather than trying to estimate the whole thing at once. Having discrete steps with time estimates allows you to have checkpoints throughout the project so you can see if you are falling behind expectations. Tracking measurable progress frequently is the best way to stay on budget.

You mentioned that you’d be working in NLP and Hadoop, which are both new to you. Fortunately a lot of people are experts in those areas and would probably be happy to help you. While they won’t do the project for you for free, they can point you in the right direction and help you avoid costly mistakes.

–Jared Friedman

Dear YC,

Sometimes we (a software startup) have disagreements about what to focus on. Should we spend our time making one individual customer more happy, or build new features that will have benefits over the long term? Until now, we’ve been defaulting to the individual customer, but this has caused some stuff on our roadmap (bigger, major features) to be delayed in favor of smaller bug fixes, feature requests etc.

Is it always the right choice to “build the company one customer at a time“, or when should we draw the line and focus on the big new thing no customer asks for (yet)? Is there a trick to make these trade-offs?

Sincerely,

Short Long Game

Dear Short Long,

Ah, the perpetual product prioritization juggle. How do you choose what to dedicate resources on among the new features asked by customers, fixing bugs in the existing product, and building features that are part of the vision of the founders?

I recommend startups sort each of these lists by their impact on the company’s core metric that they’re trying to optimize. Basically, that means sorting them by their impact on the startup’s growth. For most companies that’s probably going to be revenue.

When I think of growth, I always think of it as a function of two numbers : conversion rate and churn rate. So you should be asking yourself at any time which items, if I build them, will get me the most new customers. And you should be asking yourself which items if I don’t build them (or fix them) will I lose the most customers.

The latter is usually the most eye opening for founders when they finally ask themselves this honestly. Most of the time, the features asked by customers are not ones that they’d leave over if not built immediately. They’re nice to have, not need to have. When resources like time and energy are limited in a startup, knowing what not to do becomes invaluable.

One common mistake I see some founders make when they can only work on one thing at a time is choosing an item that they think will make the most difference and taking too long to implement it. When you can only dedicate resources to one project at a time, then you have to make sure you also calculate the opportunity cost of not implementing other items on the list. Building a feature that takes 6 months to implement at the expense of everything else would probably not be ideal, especially if the second biggest impact to growth is a bug that could be fixed in a week.

Sometimes the answer is clear and it’s obvious that you must fix a critical bug over everything else. Boom, easy win. Sometimes it’s not as clear and your gut tells you that the feature no one asked for but is in your vision is the idea that will make the most impact on growth. That is where you, the founder, earn your equity. Time to make that tough decision! It may or may not work out, but at least you’re not making the decision arbitrarily. If it doesn’t work out, learn from the mistake, resort and move forward quickly.

If you do it right, your company eventually grows to the point where it can work on each of these lists simultaneously.

-— Kevin Hale

Have a difficult question you’d like to have answered by a YC partner? You can ask us here or email your question to askyc@ycombinator.com. All published questions will be anonymized.

Sign up for weekly updates from Y Combinator.