Current users have until April 28, 2020 to use the site and access their data. Details and suggestions for saving a copy of your Voo2do data are below.

I want to thank everyone who tried Voo2do over the years. Voo2do changed my life: it taught me new skills, connected me to amazing people, and got me great jobs that have shaped my whole career. It also got me sued (bogus!), which generated some stress and notoriety but ultimately went nowhere. But most importantly, it helped a lot of people. Over 130,000 registered, and probably tens of thousands seriously used it to help themselves achieve their goals. That’s what I’m most proud of as I think back on the 15 years(!) of this project’s life.

You entrusted this little website with your productivity. I hope it was useful and pleasant, and that you’ll take the most valuable parts of the Voo2do approach and use them in whatever new system helps you achieve your goals.

Read on for further details to help any remaining users with the transition.

Service to end on April 28, 2020

On April 28, 2020, the Voo2do service will shut down. Any data saved in Voo2do will no longer be accessible after that point. As a free service, support has never been guaranteed for Voo2do users, and in the past couple of years you’ve probably seen signs of neglect such as expired security certificates and long periods of unintended downtime.

Because my personal and professional focus has shifted, and there are very few ongoing users of Voo2do, I can no longer justify the time and cost required to maintain this service. Therefore, Voo2do will officially and permanently shut down. I’m sorry for any inconvenience this may cause, especially because if you’re still using Voo2do after these years of neglect, you must really like it. :(

How to export your data

Prior to the shutdown, you can download a copy of your data in a few ways:

• Copy and paste the content of the tasks and notes pages into a document you can save elsewhere.

• Use your browser’s print function to create a PDF or hard copy.

• Under your account > backup/restore your data, you can download an XML file containing all your tasks and notes. Unfortunately, I’m not aware of any tools that can load this backup format aside from Voo2do itself, but it is a structured text-like file containing all your data. You can explore this file in most web browsers, and any programmer familiar with XML should be able to write code to extract relevant data if needed.

Thank you

I appreciate your interest and support for Voo2do. I’ve gotten a lot of kind notes from users over the years, and had some powerful “small world” moments when I’ve encountered users of Voo2do unexpectedly. I will always be grateful, and a little stunned, that this little project was helpful around the world.

TLDR: 1c rinsed rice + 1c water, high pressure for 15min, 10min natural release.

Prep time: about 3 minutes.

Cook time: about 25 minutes.

Ingredients

• 1 cup long grain brown rice
• 1 to 1 1/4 cups water

Directions

• Rinse rice and drain. (If you aren’t rinsing the rice, use more water - 1 1/4 cups; if you’re rinsing thoroughly, use just 1 cup.)
• Add rice and water to Instant Pot.
• Cook for 15min on manual high pressure.
• Allow 10 minutes after cooking (“natural release”)
• Once the keep-warm timer shows 10m, release pressure, open lid, fluff, and serve.

Note: The ratio of rice/water may need tweaking if you’re scaling up.

Ingredients

• 200g sour cream
• 2 cups of sugar (recipe calls for 2 middle-size glasses, which are ~6oz, which mom says is a lot)
• 200g margarine or butter
• 2T vegetable oil
• 1/2t baking soda, activated with a bit (~1T) of vinegar
• 2 eggs
• 200g raisins
• Vanilla extract or other flavoring
• Flour - until it achieves the texture of thick sour cream

Assembly

In a mixing bowl, combine (in this order):

• Sour cream
• 2 eggs
• sugar
• raisins
• vanilla
• vegetable oil

Then melt the butter, not too much - cool it off. Pour in a thin stream into bowl, mixing constantly.

[Ed: There is no mention of when to add the flour or baking soda.]

Don’t forget to set aside a piece for me, OK? Kisses, Y.M.

Start the oven at 350-400F. When the batter rises, immediately turn down to 300F.

Bake in a hot bundt pan, well coated with butter.

The recipe is here:

• Eat Within Your Means: Pressure Cooker Lentil Soup

Notes on cooking it:

• Benefits from some meat for variety/flavor. I’ve tried sausage, thick-cut salt pork, and chicken, all good.
• Cut down on the paprika (to one-third or less of usual) for kids.
• Potatoes are optional.
• Cabbage is great. Saute it with the other veg.
• Extra celery is good.
• All the water tends to get absorbed into the lentil mass. It might be good to add enough that you actually get soup rather than stew, but I’m not sure I have room for that.

A slow roast using sous vide and finished with a garlicky crust in a convection oven.

Prep time: about 20 minutes.

Cook time: 20 hours.

Temperatures: Cook sous vide at 131F. Finish in 450F convection oven for 7-8 minutes.

Ingredients

For the sous vide cook:

• 1 roast, 3-4 lb (I used a top sirloin roast from the local butcher shop and it turned out fantastic. Thicker cuts are preferred.)
• Rosemary (fresh or dried)
• Thyme (fresh or dried)
• Garlic powder
• Salt and pepper (not too much salt, it’s not needed and could ruin the jus)
• 1-2T butter

For the finishing rub:

• 8 cloves garlic, crushed
• 1T each Rosemary, thyme, or other herbs
• 1T Cumin and/or other spices
• ~5T Olive oil

Try next time: horseradish (especially in the finishing rub).

Cooking

Rinse and dry meat. Coat with S&P, herbs, spices. Bag with butter. Sous vide at 131F for 12-24 hours (I did about 20h).

Before serving, preheat oven to 450F/convection. This is also a good temperature for roasting oiled/seasoned veg, like halved small potatoes (~25min) or broccoli (~10min).

Combine rub ingredients in a bowl.

Remove roast from sous vide bag, saving juices for serving with the meat. Pat dry with paper towels. Cover with wet rub. Place on roasting rack or baking tray in oven. Cook until a nice crust forms, about 7-8min.

Serving

Slice thin. Plate with a spoonful of jus.

See also

• The Recipe Google Recommended, which I’m mostly just condensing here

I started my career as a software engineer, so I naturally empathize with this group. But since I switched to product management a few years ago, I’m also acutely aware of the challenges engineers can pose. There’s a natural tension between PMs—who always want more things faster—and engineers who are on the hook to build and maintain systems. You can’t solve this tension; it’s inherent to the responsibilities and cultures of these roles. So your best bet is to negotiate it from a position of mutual trust and respect.

Unfortunately, there are some dangerous pitfalls that can undermine that trust and respect. The ones below are especially pernicious because they’re tempting.

1. Lie about how successful we’re all gonna be

Let’s face it: the median PM is about 0.00001% as good as Steve Jobs. But thinks he’s about 10% as good.

One reason it can be tempting to tell this lie is because many PMs rely on it personally. Sure most new products fail, and most startups fail. But they don’t know me and my product. We’re unstoppable.

If you have this deep belief, this faith that you will ultimately succeed: nurture it for yourself. Do not tone down your ambitions and pick easier problems. Rather, accept that on the way to your big wins you will have setbacks and grinds. You will painstakingly build and ship things that turn out to be dead ends. Good product management help you get right faster, but it’s still through an iterative process, which means your big wins come through a lot of small steps.

On the other hand, if you say “here’s a sketch of the new app, once you build these three screens I’m confident 100k people will download, we don’t need no marketing plan”… well, you’re setting everyone up for disappointment. Either they’re already jaded enough to tune out that hyperoptimism, or they will be in two weeks.

2. Try to substitute micromanagement for vision

Lots of the work of a PM is just good follow-up: documenting decisions, resolving conflict, fighting fires. But a great PM will do all of this in the context of a vision that excites and motivates the whole team. This doesn’t have to be a vision you created, but it is your responsibility to understand it and make sure everyone on your team gets it too.

That doesn’t mean every coder has to understand the nuances of buyer motivation. But your goal is to promulgate a vision that everyone can get behind, not just in a grand inspiration sense, but in a way that shapes their daily decisions. For engineers, the product vision is often the first and broadest guide to knowing which stuff needs to be built to Advanced Super Scalable Polished Quality and which can kinda be glued together. If you find yourself needing to micromanage these sorts of technical tradeoffs, maybe the real problem is they don’t get the vision.

3. Don’t listen

You’re an exceptionally qualified, smart, successful person. That’s why you’re managing this product, right? Well, everyone you work with also knows they’re smart and well-qualified, and a bunch of them are pretty darn convinced the company would be a lot more successful if it just listened to them. They have deep expertise. Often they are right.

You’re the personification of the company’s direction, at least for this product – so you should listen to them. Just like listening to users, this can be very revealing. If everyone in the company says that we’ve only maintained feature X because the founder has an inexplicable obsession with it even though nobody uses it, they’re probably right.

Also like users, the people you work with will want conflicting things. Some engineers will hate the database layer, others think it’s the coolest part of the whole product. You can’t please everyone, but you can listen to everyone. When you need to scale beyond just face-to-face conversations, simple things like a transparent way for colleagues to submit ideas can work well. The critical ingredient is feedback. So give everyone a way to file issues for whatever they care about, set an expectation for how often they’ll be reviewed by the product team, and make sure they get notified (even if the notification is “sorry we’ve got bigger fish to fry”). And when an oft-requested feature does ship, thank everyone who asked for it by name.

4. Indulge bad work (including by engineers)

Have consistent, high standards for what level of work is acceptable. It’s easy to say but harder to follow through, and you have to follow this one through.

This is one area where management and parenting have some common ground. Like all humans, engineers don’t always live up to their own standards. We rely on our peers to value and demand good work, even when we ourselves are lazy. But if our laziness is always accommodated, we’ll get used to it, and won’t bother pushing to do our best.

When you’re managing a team with multiple different skillsets, it can be hard to know when you’re seeing bad work. So the best thing you can do here is make sure that each functional team has its own standard bearers. People who can evaluate the work others are doing as it happens, and make sure that the codebase or design or product roadmap is something to be proud of.

On the other hand, suppose you have an engineer who often does lousy work. The other engineers know this because they’re completing his features and fixing his bugs. If you (and the engineer’s direct manager) treat that dummy the same way you treat any other engineer, you’re sending them all the message that you don’t appreciate the difference. On the other hand, confronting the problem in a firm but respectful way—either with the individual or their manager—reminds them that the quality of their work does not go unnoticed.

5. Refuse to prioritize

There are more good ideas than there is time to execute them. Therefore:

• Any work you choose to do will displace other work you could be doing instead.
• Just because some work will generate more value than it costs doesn’t mean you should do it.
• You should do something when it has the best benefit-to-cost ratio of all the things you could do.

These things should be obvious. An engineer can work on one thing at a time. A team of N engineers can work on N or fewer things at a time.

Yet so many product leaders think they can just identify 500 things that seem worth doing and then blame the engineers when only 15 get done, and it’s the wrong 15. That’s like an investment advisor saying “here are a bunch of investment options, I think some of them will go up in value” but not telling you how to balance your nest egg among the options. This means the job isn’t done.

Prioritizing can be hard for a PM to do, because we don’t always know what a feature is truly worth, or even how much work it will take to build. But the fact is your team will always work through things in some order. You can choose whether that order is something you determine, or if you’d prefer it be shaped by the whims, preferences, competing interruptions, and gripping Hacker News articles of the day.

6. Take all the credit

Credit can motivate people. As a locus of communication in the organization, a PM has a lot of capability to distribute credit. And even to create credit, by explaining the great work your team does. You can and should capture some of this credit for yourself, as it is one way you develop your career and increase your influence. Plus it feels good.

But don’t overdo it. And this isn’t just about what you put in slide decks or announce in meetings; you can cross a line by giving yourself a goofy nickname (“product overlord”) or failing to include the right colleagues in meetings.

As one of the more visible leaders on a product, you’ll already get a lot of credit for its success (and blame for failures). Don’t hoard it; credit is not a scarce commodity! Help those who do good work. Maybe it means they’ll be more likely to rise in the org, in which case you’ve nurtured a relationship that could help you again someday. And when a team feels recognized for their work, they’ll be happier and perform better.

7. Always expect firm deadlines

Accountability is a core value of high performing organizations. If you need a routine change to some part of your product’s layout or content, it should ship efficiently in a predictable amount of time.

But much of the work in a software product is novel to your team. Designing and building a feature can expose complexity that wasn’t foreseen. This is the nature of making software; an organization where this never happens isn’t taking enough risk. And so when this happens, you can choose to accept that estimates have changed and rework your plans, or you can try to push people to meet their original deadlines.

Pushing makes sense if they’re a couple hours off because they spent too much time playing ping pong. It doesn’t make sense if they’re months off because the platforms you rely on don’t offer the functionality you expected. But without the relevant technical background, it can be hard to discern trivial from impossible.

Still, some PMs ignore that complexity and always push, because they assume the engineers are lazy and need someone to crack the whip. But good PMs know that missed deadlines—although they hurt—are a learning opportunity. If this approach is too hard, is there something we can simplify and still get most of the value? Is there something similar we can reuse? Was the request really infeasible, or did we bungle it somehow? How can we do better next time?

With that learning outlook, missed deadlines become an improvement opportunity for everyone. But there will be a lot of complex judgment calls that ensue, including ones that call engineering decisions into question. The need to handle those well at every level—and avoid being bamboozled by engineers who can say “that’s impossible” to anything they don’t like—is one reason it’s helpful to have technical smarts at the very top levels of your organization.

Be good. Don’t be bad.

In an organization full of people who are (1) smart and (2) always learning, it’s hard to know everything all the time. Most of the fails listed above boil down to this:

Don’t pretend to be certain when you’re not; engage everyone in building knowledge.

Building good products is about assembling the right knowledge and making it operational. Helping engineers prioritize, get the right resources, and understand real-world performance can turn them into your greatest allies. Drown them in politics, unproven ideas, or other distractions, and you’ll soon have the mutiny you deserve.

Thank you to Scott Macmillan, Alin Popescu, Rob Bushell, and Aaron VanDerlip for their feedback.

Prep time: about 15 minutes.

Cook time: about 25 minutes.

Ingredients

• 1 lb seafood medley, thawed (shrimp mussels calamari scallops)
• 2 ribs celery
• 1 medium-large onion
• 1 lemon, quartered and seeded
• 3 cloves garlic
• 2 cups fish stock
• 3 tsp flour
• 3 Tbsp butter
• 1/2 cup milk
• 2 tsp capers
• 4-6 slices preserved lemon, minced

Cooking

Heat olive oil in a pan on high. Add seafood, S&P, 1/3 of garlic. Brown for flavoring. Remove from heat.

In a pot, start stew base. Heat olive oil on medium-high. Add celery, onion, 2/3 of garlic, S&P. Cook until softened.

Add seafood and stock to stew. Retain pan. Reduce heat to simmer.

In reserved pan, add butter and melt on medium heat. Scrape fond into butter. Once melted, add flour (sprinkling to distribute). Brown slightly to form roux, about 30s-1m. Once browned and smelling nutty, add milk. Stir to absorb fond and homogenize. Add mixture to stew.

Add capers and preserved lemon.

Simmer to thicken as desired, at least a few minutes. S&P to taste.

Serve as a rich bisque or stew over rice.

Turns out there is. A disciplined approach to product management works, and if you look behind most “overnight success” stories, you’ll find years of disciplined effort. And while every product expert will have their own set of tricks for each part, the essential principles of disciplined product management are so simple, I can list them right here:

• Know that to succeed, your product must be desirable, feasible, and viable.
• Identify your assumptions – the working theories of how your product will be all of these.
• Iteratively test and refine your assumptions.
• Prioritize testing your most prevalent and uncertain assumptions.

In this post, I’ll explain how these pieces fit together to enable a disciplined approach to some of the biggest challenges faced by ambitious companies.

Hope is not a strategy

Some of the best products of all time seem just plain lucky. Facebook started at Harvard, and its exclusivity and prestige drove incredible adoption. Viagra was originally studied for heart disease, but had an unexpected effect on male study participants.

On the other hand, lots of successful products are enabled by uniquely deep knowledge about their market–they’re just plain smart. Snapchat understood the challenges of permanent social media and solved them in a way that frees young people to share much more than they could before. Nosefrida understood baby anatomy and the priorities of harried parents and made the Snotsucker, a huge success despite its goofy name. (Never heard of it? Ask anyone who’s had a baby in the last 5 years.)

So if you want to make a successful product, you want to be both lucky and smart.

What’s the strategy for being lucky? It’s not hope or positive thinking. Statistically, the only thing you can do to increase your chance of getting lucky is to take lots of shots on goal.

What’s the strategy for being smart? It’s knowing more than everyone else. And the way you get there is through relentless learning, focused on the subjects you really need to understand better.

No matter where your product is right now – from nascent idea to revenue-producing juggernaut – you want to be as lucky and smart as possible. Fortunately there’s a technique that will help you optimize both of these, if you do it right.

Iteration to the rescue

By definition, you can’t control how lucky you are. But you can control how often you roll the dice. Or as Gretzky said, “You miss 100% of the shots you don’t take.”

You also can’t just will yourself to be smarter. If you’re learning chemistry or woodworking, you can study with an expert. But in competitive product markets, your best bet is often some form of trial and error. If you want to sound like a scientist, you can call this experimentation.

If you only care about luck, raw trial and error is sufficient. Take a guess at what you think the product should be, build it, and if you’re lucky it will sell like hotcakes. If that didn’t work, guess and build again. This great strategy is guaranteed to work given infinite investor dollars.

On the other hand—if you only care about being smart—then shipping is not necessary. Deep knowledge can be cultivated easily in narrow niches, where nobody interested in actually changing the world is trying to outdo you. You can append an endless series of initials after your name using this approach.

But you care about both luck and knowledge. So you’re going to iterate:

• Each iteration will be time-boxed, so you’re forced to run aggressively with your best guesses instead of overbuilding.
• Each iteration will be tested with the real market so you can learn something new from a human outside the building.

Have you ever seen a product leader (or team) write down a big to-do list of their own ideas, and say that if we build these we’ll have customers lining up to give us money? But we haven’t yet talked to any customers yet, because obviously we need the product first!

If this is the first product release, they’re wrong but they might figure it out soon. If this is the second, third, or tenth time you’ve heard the same thing, they’re misunderstanding the fundamental work of product development. This is a severe misunderstanding – about as delusional as hoping that when your beautiful daughter goes to Hollywood, a smart agent will discover her and make her a star.

But the iterations are just a structure. You also have to put the right stuff into the structure.

Picking what you iterate on

Product discovery is an unpredictable process that will always rely on luck, intuition, and educated guesses. You want to get more educated, but where to start? Like any project, the best approach is to do the riskiest stuff first.

This is at the core of any disciplined approach to a novel endeavor. In software engineering, it’s sometimes called Worst Things First. The idea is that if you do the most difficult or risky things first, you have more flexibility (in design direction, schedule, etc.) to respond when things don’t go as you’d hoped.

Here’s an example. Say I want to start a new social network. It clearly has to have a way for users to log in, so I’ll start by designing an amazing login flow. It’s gorgeous, usable, and my test users all say it’s the smoothest they’ve ever seen. Hooray! Launch.

Sadly, nobody is using my social network because it’s a ghost town, and all my effort on that login system is totally pointless unless I figure out how to motivate users to join. Instead of building that, I should have worked on better understanding what would motivate people to use my social network. Maybe the next big social network doesn’t even need a login system?

That’s why you want to test your riskiest assumptions first. And do that, you need to do two things: list your assumptions, and prioritize them by risk.

How to list your assumptions

Step back from the details of your business and pretend you’re advising another company in the same field. What will it take to have a successful product?

Let’s continue the social network example. To be a successful social network, a product has to:

1. Have a significant volume of users
2. Engage those users in frequent interactions via the product
3. Appeal to advertisers

Then break down each of those. For example, to achieve a significant volume of users, we have to motivate the first signups. That probably means we have to start with a close-knit group that would get a lot of value from interacting with each other. We could do this like facebook did, with a single college dorm, or like twitter did, with a cadre of bay area tech elites. If we choose the “cadre of elites” approach, we have to find a group of elites we can attract. Suppose we target elite athletes by giving them a new way to engage fans by reporting on their training regimen. Then we are assuming (1) athletes want to engage their fans more, (2) they would be willing to share information about their training regimen, and (3) they would consider using our product to do that.

You might have noticed these are all assumptions you can test fairly easily by interviewing some elite athletes (if you can’t reach them to get interviews, that’s another set of assumptions to unpack). Once you break your product goals down like this, you can start to fill your iterations with experiments that shed some real light on your assumptions. But even listing out the assumptions can help you learn something. For example, if you realize that two of your assumptions contradict each other—like if you need early adopters who are both college students and have lots of disposable income—then you can step back and rework your plan.

If you’re not sure about where to start, remember that a successful product has to be desirable, feasible, and sustainable:

• Desirable: someone has to want what you’re offering. This is the main area that failed startups miss.
• Feasible: you have to be able to deliver what you’re offering. Unless your venture includes a component of hard technology, this probably isn’t a huge risk early on.
• Sustainable: the cost of delivering your offering, long-term, has to be bearable to your organization. Typically, this means you’ll sell enough to cover your operating costs. This is usually a later-stage question, but it’s surprisingly easy to convince yourself that you’re creating value when you’re really just moving it from investors to customers.

If you’re really at a loss for where to start listing your assumptions, begin with “people desire to use this product” and break it down from there. It will force you to state your best working assumptions. When you get to the assumptions that feel like going so far out on a limb that you’re really not sure they’ll seem correct in a couple of weeks, that’s what you want to test in your next iteration.

Prioritize the most prevalent and uncertain assumptions

Continuing our example, suppose you’ve got a handful of relatively specific assumptions. In the case of a social network seeded with elite athletes, we might have these among our assumptions:

1. Elite athletes will use our training tracker (individually, even before there is a large crowd in our network).
2. Anywhere elite athletes are posting content, their fans will follow.
3. Fans will interact with each other around the athlete-provided content.
4. Tennis stars have a more devoted individual fan base than Football stars.

Because we want to test the riskiest stuff first, we want to start our validation efforts with the assumptions that are most prevalent and most uncertain.

• More prevalent assumptions are those that underpin our product’s success in multiple areas. In this example, our ability to engage elite athletes individually supports all of the other assumptions we’ve listed. If we don’t succeed at engaging that critical initial user base, we’d better try a whole different approach.
• More uncertain assumptions are those that we have less confidence in. For example, once elite athletes are talking about their training experience, it sounds like a pretty safe bet that fans will want to see what they’re saying. On the other hand, because elite athletes are likely swamped by all sorts of appeals for attention, getting them to use our tracker is a fairly uncertain assumption.

For bonus manager points, you can visualize these in a 2x2 matrix:

Now let’s see how our assumptions above fall into this matrix.

1. Elite athletes will use our training tracker (individually, even before there is a large crowd in our network). — This is key question.
2. Anywhere elite athletes are posting content, their fans will follow.— False confidence booster. This is prevalent, but also pretty darn likely, so proving it right would be futile.
3. Fans will interact with each other around the athlete-provided content. — Also seems prevalent but pretty likely.
4. Tennis stars have a more devoted individual fan base than Football stars. – Distraction, because although it’s an interesting question, either type would likely be sufficient for us to get off the ground.

Now go do it!

Writing down your assumptions is a great first step toward running your product in an efficient, disciplined way. Even though you’ve probably got an idea of what your high-priority (i.e. prevalent and uncertain) assumptions are, getting a big list written down — and identifying which ones you’re going to focus on and which you can ignore for now — can ease some of the panic you feel when there seem to be a thousand Big Important Things.

And you don’t need anything special to get started — whiteboard, post-its, google docs, or pencil and paper will do. You’ll naturally tweak the specific techniques after a few iterations!

Feedback? Questions about this or another aspect of product management? Let me know.