First Steps Towards UODP

by Viacheslav Kovalevskyi

We have not even defined yet what UODP is. However, I am already getting random questions like: "how can I try this? do you have any formal steps for beginners?"

This small article is going to address precisely that question. Without further ado, here are the ...

Steps Towards UODP

  1. Define the set of problems that you were thinking to solve (not project or features)
  2. Define the set of real customers impacted by those problems
  3. Assign tasks to onboard specific customers to the solution that solves the problem
  4. Pick your team members who will have a personal task to onboard the customer
  5. Onboard the customer
  6. Generalize solution for the rest of the customers

Common Mistakes

Working Backwards From Technology Instead of a Problem

Starting with a technology/service/feature and trying to find where to apply it. When a team first attempts to practice UODP, they usually would start from searching for problems that can be solved with technology/service/feature that they have on the roadmap. Instead, the team should be starting with revisiting customer's problems that they want to solve (irrespectively of technology/service/features they are currently building).

Main symptoms:

  • switching target customers if a current customer does not have a problem that can be solved with technology/service/feature that is in the development
  • promoting to the customers a technology/service/feature instead of learning more about existing customers infrastructure and existing customer's problems

Not Onboarind the Customers

Another big mistake is to ignore items 3+ on the list. Again, I've seen this multiple times in my life, when a team only starts using UODP, what usually happens is that it focuses on validating the problem (which is a nice thing), however, completely drops the steps that confirm that solution solves the problem. It usually looks like this:

  • validates the problem
  • builds the solution
  • releases the solution and claims that the problem now been solved

While such a process is much better already, since it is starting from the validated problem, one can not argue that the problem is solved. The only proof that the problem is solved is when a real customer that had this problem is onboarded to a new solution.

Not Focusing on Main Problem(s)

Another issue that I've observed: since almost any problem can be justified by identifying customers who had it, one can end up with the roadmap that has tons of features in it that solving "validated problems". In such a case, a team can still deliver an unsuccessful product with zero customers using it.

FAQ

Q: What if customers going away?

A: Customers might decide not to proceed indeed, and you have already spent engineering cycles on onboarding them. However, in reality, this is rarely the case if you are doing your job right. But if you want to protect yourself, always have several customers that you are onboarding.

Q: Would this be over-optimization for a specific customer?

A: While this is a common theoretical concern, it rarely the case in real life. On the contrary, it is much more likely, by building a generic solution to end up with no customers at all.