I came across this blog post, titled This Will Only Take 2 Hours.

Go read the post. I’ll wait.

Ok, back? That post is both insightful and frustrating.

Insightful, because the author Henley correctly points out that requirements for products can be more complex than they originally seem.

Frustrating, because Henley is making a whole bunch of assumptions about what the product is for, which predictably cause the scope creep that he writes about.

As an exercise, I’m going to lay out a few of the requirements and analyze them as I would a design doc at my company.

PasteUrls

Goal: “A desktop program that monitors my clipboard for URLs and logs them automatically.”

[lincoln] I need a few examples of ways this will help you – what are your use cases?

  • Include Pause/Resume capability, including “pause for 5 minutes”

[lincoln] If this were a command line app, you could just ctrl+c it and then put sleep 300; before running the script again. Don’t need to build this in first version.

  • Show visually when it is paused

[lincoln] Just launch it in a terminal, it’s easy to see by switching to the terminal whether it is running. Cut.

  • Autolaunch

[lincoln] Cut this unless users ask for it.

  • Log format should include: timestamps, unfurled url info, and source application

[lincoln] Timestamps are obviously critical, but easily added. I would skip the unfurl though - use the UNIX philosophy and write a separate program to go grab metadata if you need that. Source app: may as well log this info if extremely easy, otherwise skip this feature unless users require it.

Analysis

Ok, so let’s assume you’re a software engineer faced with this requirements doc.

My first question to our customer Henley (which I wrote in the doc) is, what are the use cases? How will this help your life?

When I’m reading it, I’m thinking “gosh, maybe this URL logging app will be useful, but I sure don’t know how useful it will be”. Maybe Henley knows why he wants this, but he isn’t sharing. Sometimes if you’re the programmer (or product designer) you’re in this epistemic state. What should you do?

You have a few options: Ask your customer more ‘whys’ to get further detail about what they want; make assumptions about what they want; or build them something and see how they react.

In a work environment, you should pretty much always ask ‘why’ first. I get very frustrated when engineers I manage fail to ask this question. It usually means they’re accidentally, without realizing it, following the path of making assumptions. Customers often over-specify their vision; it’s your job to figure out how to build it quickly.

If you are getting stuck on the ‘whys’, either because your customer doesn’t actually know how to articulate what they want, or they’re inaccessible – then the next step is to try to figure out how you can get unstuck and learn what you need to know to design the next iteration.

A non-technical product manager might not know how expensive things are to try, but fortunately you’re an engineer and you know how to look on Stack Overflow to figure out what’s in the clipboard. You imagine “gosh, this could be a 2 hour project if that api is simple”.

Now’s your chance to shine! Build your customer the simplest possible thing that could plausibly do what they need.

Before going onto the next section, take a few minutes to practice – plan out how you might build an MVP. Throw out unimportant assumptions the customer is making. How fast can you go?

Lincoln’s Minimum Viable Product

My MVP is, indeed, a 2 minute project: a command line tool which uses the OS clipboard api and grep to detect urls, outputting those urls to stdout, easily redirectable into a log file. Every other feature is unnecessary for the first version, and/or easily implemented by piping the output.

Here’s my one-liner shell script on OS X:

( while [ true ] ; do pbpaste | grep http; sleep 1; done ) | uniq

The Learning Process

I’m sure our customer will come back and say this is insufficient! That they have more requirements! I’m sure they do. But I would strongly recommend trying this for starters. Let them see how it feels, then come back to us with specific feature requests. Remember, we did this work in 1/60th of the lower bound time estimate (2 minutes instead of 2 hours) and we will be learning immediately what the user wants.

This kind of speedup is only available to sufficiently-technical people who are thinking along the Product axis. It’s not available to engineers who don’t challenge assumptions and push back on stupid requirements, and it’s not available to product people who don’t know enough code to know what’s on Stack Overflow and what’s easy.

Henley’s post isn’t wrong: a lot of ways this product evolves will end up with you implementing many of the features he describes, and that work will take a lot longer than 2 hours. But we’re now much better able to prioritize those features, because our product will be in the hands of the customer immediately.