{"id":1103,"date":"2012-05-25T21:22:40","date_gmt":"2012-05-25T21:22:40","guid":{"rendered":"http:\/\/intercom.com\/blog\/?p=1103"},"modified":"2020-07-30T13:04:06","modified_gmt":"2020-07-30T12:04:06","slug":"where-to-draw-the-line","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/where-to-draw-the-line\/","title":{"rendered":"Where to draw the line as a product manager"},"content":{"rendered":"

The most important thing a product manager does is decide where their product stops and someone else\u2019s product takes over.<\/p>\n

If an app does too little then it isn’t 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\u2019s just right.<\/p>\n

<\/p>\n

Example: Time tracking<\/h2>\n

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\u2019s at this point we realise simplicity is overrated<\/a>. No amount of web fonts, HTML5 transitions, or sound effects can help a product that simply isn\u2019t earning its keep.<\/p>\n

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.<\/p>\n

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\u2026<\/p>\n

\"\"<\/div>\n

If you\u2019re building an app that helps teams order lunch every day, the workflow might look like this\u2026<\/p>\n

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

    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 \u201cIs your product a vitamin or a painkiller<\/a>\u201d that discusses the difference here.<\/p>\n

    Where should you start?<\/h2>\n

    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.)<\/p>\n

    A real world example would be TripIt. TripIt solves travel management. Their app could start with flight search, but TripIt couldn\u2019t 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 \u201cUser opens booking confirmation<\/em>\u201d. 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.<\/p>\n

    Where should you stop?<\/h2>\n

    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.<\/p>\n

    Your product should stop when the next step: <\/p>\n