Where to Draw the Line

The most important thing a product manager does is decide where their product stops and someone else’s product takes over.

If an app does too little then it isn’t be worth the cost of installation, or registration let alone the actual purchase price. Similarly if it does do too much, then it will clash with some other pre-existing software or workflow that users are already happy with. It’s a Goldilocks problem, you need to find the product that’s just right.


At an absolute minimum time tracking is just totaling a list of numbers. Now, if that was all a web app had to offer, it would be useless. Excel or Google docs does that job already. It’s at this point we realise simplicity is overrated. No amount of web fonts, HTML5 transitions, or sound effects can help a product that simply isn’t earning its keep.

At a maximum, time tracking can involve project management, budgets, contractors, invoicing, receipt tracking and employee monitoring. Applications that incorporate so many surrounding tasks tread on the toes of products already in place, in this case, Xero, Ballpark, Basecamp, etc.

Products exist to solve problems that occur in a workflow. They have a start and end point within that workflow. To understand where these points should be, you must understand the entire workflow. Let’s look at the workflow for a team ordering lunch every day…

If you’re building an app that helps teams order lunch every day, the workflow might look like this…

  1. Someone gets hungry.
  2. He or she communicates this to the rest of the team.
  3. Debate ensures about whether to go out or order in.
  4. Second debate about where to order in from.
  5. Menus for different places are passed around.
  6. A decision is arrived at quickly
  7. One person is appointed to gather everyone’s orders.
  8. That person then places order.
  9. That person communicates delivery team & cost to everyone
  10. Time passes.
  11. Food arrives, and is eaten.
  12. Orderer checks if everyone paid enough & who still owes money.
  13. Finances are settled, or the settlement is postponed until tomorrow.
  14. Some will talk about the food on Twitter or Facebook. Some will post pictures on Instagram. Others will review on Yelp.
  15. Everyone returns to work.

When you understand the full workflow, you can focus on the most concise painful subset your product solves, or alternatively the piece you can make more fun or interesting. Don Dodge has a great article titled “Is your product a vitamin or a painkiller” that discusses the difference here.


Start your product at the first step where you can add value. For our lunch example, this is probably step four. Starting any earlier would mean taking on chat products or email, rarely a good idea. (Side-note: Unstructured communication always falls back to email or chat. You can count on no fingers the amount of products who have changed this over the years.)

A real world example would be TripIt. TripIt solves travel management. Their app could start with flight search, but TripIt couldn’t add value there. The first point they can add value is right after a booking is made. By understanding the entire workflow, Tripit designed a great solution. The last thing that happens before TripIt can add value is “User opens booking confirmation”. This is the first point TripIt can add value, so they start with that email and import from there. Similarly, Instragram starts with importing your social network, or time tracking can start by importing projects from Basecamp. Good APIs and import features help your users get off to an easy running start.


Your budget, whether time or money, should restrict but never define your scope. A large budget should define how well a problem is solved, never how many problems are tackled. Attempting to tackle an entire workflow from start to finish for all types of users is near impossible.

Your product should stop when the next step…

  • - has well defined market leaders looking after it (e.g. PayPal, IMDB, Expedia), and you don’t intend to compete.
  • - is done in lots of different ways by lots of different types of users (e.g. trying to process salaries in a time tracking app would be tricky)
  • involves different end-users than the previous steps (e.g. managers, accountants etc.)

Posted via email from Pete's posterous

No comments: