linkedin email
When is a product "done" and what do you do next?
Jun 19, 2022
6 minutes read

Recap

In the previous post, I talked about how without proper checks and balances, most products become bloated in size and user experience. But it raises an important question – do teams always need to keep building new features? When is a product considered good enough or done? And what should a team do once it’s done?

Definition of done

We’ll start where most discussions should start – by defining some important terms. The biggest word to define is done, since it’s ambiguous and subjective.

All software products and their features are built to solve a user problem. Imagine your product is an actual person. Now, you can think of the problem as a user or a company “hiring” your product to do a task or solve a problem. For example, I hire Airbnb to help me find and book a stay at someone’s place. I hire my laptop to help me write things and check my email and read things. So we can redefine the question to when has my product solved the problem it was hired to fix?

But that’s still quite vague – how do we know when the problem is solved? And for how many users? Okay, let’s make it simpler. Say you could ask every user, after they use your product, whether their problem was solved? I’m making lots of assumptions here, such as:

  • Assume the user is the one buying the product (not true for most B2B products!)
  • Assume the user hires your product to solve a single problem
  • Assume the user can evaluate whether the problem was solved or not

Accounting for all those assumptions in the real world is left as an exercise to the reader. For now we’ll assume that you can magically ask all users of your product whether their problem was solved or not.

That’s a pretty reasonable way to measure how “done” a product is: what percentage of users will say your product solved their problem.

The importance of leading and lagging indicators

For most products, it’s not feasible to ask every user whether the product solved their problem. For starters, users may not care to tell you. But there may just be too many users for you to feasibly ask – if you have a million users, how would you ask every single one of them?

Sure, you can try to send a survey. But if you saw a survey from Google asking “Hey there user, did Google solve your problem,” what would you say? No, the reality is the question requires too much context to ask in a survey, and to provide every user that context is infeasible for widely-used products.

So what do you do instead? Let’s consider a hypothetical (and laughably oversimplified) example.

I have a dog that needs food every day. But I also have to go to work every day. So, I decide to build a machine that automatically dispenses dog food when I press a button on my phone. The user is my dog, and it solves the problem of my dog getting too hungry by the time I’m home.

Now, without installing a camera, how would you know whether the machine works?

Well, I could ask my dog. But I don’t speak dog, so that doesn’t work. Next idea.

What if I filled the bowl when I got home, and if my dog finished the food immediately, then the machine didn’t dispense enough food and it didn’t work. But what if my dog is just really hungry all the time, and this will actually make him overeat? Next idea.

What if I monitored the weight of the food at the beginning and end of the day, and also monitored my dog’s weight to ensure he’s not overeating? Not a bad idea.

You can imagine if we continued iterating, we could come up with better and better indicators of success. But in both instances, I utilize leading and lagging indicators to get at the underlying idea of whether my product solved the problem for the user.

That’s the gist of it. You can’t ask every user whether their problem was solved, so you need to use metrics (aka heuristics, indicators) to determine whether the problem is solved. And you might use the wrong metrics the first few times and realize you didn’t solve the problem as much as you wanted. This happens all the time, and it’s part of the process.

But seriously, how done is done enough?

That’s up to the team working on the product. Now, you might think this entire post was a bait-and-switch, and you’d be right. I said I’d tell you how to know when something was done, and then at the end I said that there’s no way for me to tell you when something is done.

But here’s why this post is still useful – you now have a framework by which to evaluate done-ness. Don’t discount the importance of this framework.

The three(ish) steps to determining whether a product is done.

Here it is defined more succinctly:

  1. Identify what problem your product or feature solves. It should be a simple and clear problem. If you asked any user of your product whether that problem was solved, they should be able to give you a yes or no answer.

  2. Formulate leading and lagging indicators of that problem being solved. These should include a good mix of metrics that help you measure, at scale, whether you’re solving that user problem or not. For earlier products or B2B products, you might have such few users that you can talk to them directly. But you still want to ask them questions that help you understand whether you’re solving their problem.

  3. Create a definition of done for those indicators to help you decide when to move on to another problem. This is critical for most teams, and in the real world, you’d probably be constantly evaluating your indicators and goals, trying out features and optimizations to reach those goals, and re-evaluating. It’s an iterative process that teams undergo every quarter. Don’t feel like your goals or metrics are ever set in stone.

  4. Rinse and repeat.. This answers the “what you do next” part of the article. The reality is that you can always invest in solving new problems, and this is the challenge of working on software products. True success comes from constantly asking yourself what other opportunities exist and how you can create more value for users.

This framework can certainly be applied to other areas as well. Software development has many overlaps with problem solving in general and how to think about time management and resource allocation. Hopefully applying this framework can be useful for you when you’re working on complex problems that require an investment of your or others’ time, effort, and resources.


Liked what you read? Subscribe to my newsletter to get new posts directly in your inbox.


Back to posts