User-Oriented Development Process Problem Statement

by Viacheslav Kovalevskyi

Many companies in this world never connect their success with the success of their customers. Some of them are doing KPIs/OKRs, doing everything right, and yet constantly delivering mediocre things from the perspective of the customers's adoption. Usually, this is because companies build generalized products (and as you know: "Building Generalized Solutions is Killing Your Product.")

Solution

User-Oriented Development Process (UODP) aims to precisely solve this problem; it is all about connecting customer success with the company's success. On a high level, this is done in a straightforward definition of done.

In this article done - means that the team has the following:

  • Well document the problem that we were aiming to solve at the beginning
  • A customer testimony that includes confirmation that the customer is using the product/solution/project and it solves the problem described above.
  • KPIs that confirm customers' testimony

The process of getting to the done is called: "onboarding customer." As you can see, you can onboard the same customer multiple times by solving different customer's problems.

Implementation

To start the implementation of UODP, the pre-requirement is to have a list of customers that have to be onboarded; they should be sorted in the prioritized order.

From this, we will identify the highest customers on this list that we can sit with and partner with. UODP does not work if a customer does not want to be with us in the same room. A customer has to be a partner; we should be launching with customers, not at them.

When we have a pool of customers, we can start building a pipeline of ICs in charge of onboarding. While this IC can be anyone, EM/Eng IC/PMT/TPM, it usually works best if onboarding POC is an engineering IC. This is important since the "last mile" of onboarding often requires quite deep engineering knowledge of the stack to proactively identify which parts can be shortcutted and which need to implement last-minute fixes or features.

The person in charge of onboarding a customer should ideally be:

  • IC or eng leader that can deliver features/fixes or influence org to do so
  • Act 10% of the time as outbound PM.
  • Act 10% of the time as TPM.

Onboarding Process

Create an onboarding tracker. It can just be a Google Sheets document with the following columns:

  • customer name
  • Customer team (quite often, you can be onboarding different teams within the same customer)
  • Customer side contacts (should be the concrete name)
  • Your side contacts (specific DRI)
  • Stage of onboarding
  • Link to a ticket/doc/etc

With a pool of customers and DRIs, we can start the onboarding process that includes the following 3 stages:

  • STAGE 0: Pre-engagement, collect all the data:
  • Add the customer name and you as a DRI to the tracker.
  • Create a ticket and assign it to you (add it to the tracker.)
  • Find all the stakeholders in the company who are already working with the customer.
  • Create a centralized document that describes all the problems we know about from the customer (and existing workstream)
  • Create and execute group/company-wide reviews to present everything you know about the customer, where everyone in the org should be able to learn about the customer and ask questions.
  • STAGE 1: initial engagement:
  • Create a v-team for onboarding customers that should include a direct way of communication with the customer (Slack/Discord/etc.)
  • Create initial sync with the customer and present the document to:
  • Confirm that we have everything (no other joined initiatives we have been missing).
  • Learn about problems that customers have.
  • Build and own the roadmap (should be sub-tickets to the main ticket).
  • STAGE 2: active engagement

Many customers will have the same problems as others, so, at any point, each layer (customer => problem => eng initiative) has many-to-many relationships. That is why building a hierarchy of bugs/tasks/features is essential to represent it. Suppose one person onboarding customer X and another onboarding customer Y. In that case, they might be adding comments to the same problem that both customers (X and Y) require a company to solve.

It is suggested to start the UODP process before the official planning seasons so your customer's DRIs can STAGE 2 right in time for the planning.

Incentives Alignment

An essential part of the UODP process is adjusting incentives during your company's performance review cycle. UODP will only work if you connect the customers' success to the DRI who onboarded them. A person that does onboarding, by nature, will be asked to prioritize customer's needs over everything else. And should be recognized for that. For example, if a customer's ask might be solved by updating docs, DRI should be updating docs vs. building a new feature or product. This often conflicts with what is expected to be evaluated during the performance review process of engineers (this is the case in almost any company). If not addressed, this will incentivize people to go back to the usual way of execution: prioritizing work that will get a person to the next level vs. work that will lead to customers' success.

Main Biases Against UODP (We Heard Them All)

We are over-optimizing for one customer.

The most frequent one, by using UODP we will be over-optimized around one specific customer. A long answer to this is, "Building Generalized Solutions is Killing Your Product."

Shorter answer based on very subjective experience: It is much more likely to build a product around one customer/use case (so, at minimum, have one happy customer) and find a way to scale it vs. trying to build a generalized product and onboard at least one satisfied customer on the day one.

Will customers always know what to build?

"If I had asked people what they wanted, they would have said faster horses." Ford.

While this is true, customers often need to learn what they need/want, so we should not confuse product vs. problem. UODP is about solving problems that customers are having. While customers might not know which products they will need ("faster horses"), customers always know what the main issues they are facing in their lives (time to get from A to B takes too long). So, while UODP makes sure that we are focusing on the real problem that real customers are facing, UODP means something other than that we will build a product precisely as customers describe it. So, let's distinguish listening to customers about their problems from listening to them about how they want them solved.

Is this a job for the PM?

To some extent, this is a job for a leader that has deep technical knowledge about the product; it can be EM/PM/TPM/IC, but it does not matter since none of these roles canonically can represent everything that will be required from the DRI that is onboarding customers. That is why it is essential to find the right leaders when assigning customers to them.

Usually, the best PM can describe the products that will cover 90% of requests from any of the main customers. However, the remaining 10% that are unique to each customer will ultimately determine if we are successful in the onboarding process.

But one of the most important reasons is that if this job is done by PM only, it can not scale since PM, at best, can focus on only so many customers at a time.

However, there are other parts of UODP where PM can and should play critical roles, specifically:

  • Facilitate customer relationships and maintain a list of customers who are ready to be onboarded
  • Make sure that we are onboarding the right customers, who are representative of the bigger group of customers
  • Represents customer who have NOT agreed to be with us in one room

Appendix Learn More

There are many places where you can learn more(external):