One of the common questions that I'm getting from people reading this blog: "fine, you have all these articles, but can you give me a clear answer of what is UODP?". Well, today is the day when I will start answering this question.

In short, user-oriented development process (UODP) is an execution technique that includes several aspects:

• how to identify the right customer
• how to identify the right problem
• how to set the right goals

Today we are going to cover part number one:

How To Identify The Right Customer

Each customer has three subgroups. They all can be the same person or completely separate departments within one big enterprise. These subgroups are (sorted by priority):

• decision criteria enforcers
• integrators
• end-users

You have to address them one by one, starting from the top.

Decision Criteria Enforcers

To illustrate this group, let's take an example: we want to build a service for machine learning practitioners. Now imagine if we're going to onboard a customer from the medical institution. Since our service will be used to process user's personal and medical data our decision criteria enforcers, in this case, can be:

• government of a particular country that enforces standards like HIPAA
• the company security team that might require specific compliances to approve services
• the legal team might need specific aspect product's term of services to be in place

It is clear from even these examples that it does not matter how excellent and fantastic the service/solution/product is. Our hypothetical customer still can NOT use it (even from a legal point of view) unless compliant with all the specific requirements.

Such a situation means that one does not have to have the best service in the world. One needs to have the best service among services that satisfy the requirements of decision-makers.

Good news: it makes life much easier since your MVP does not have to be even on the same level as another service created by shiny new startups.

Bad news: your MVP will need to have all the required certification and functionality (so actual work might be even more extensive).

To illustrate the point, let me ask you to recall the situation where you were asking yourself: "why does my university/employer/company/etc force me to use this horrible tool? I know hundreds of tools that do these tasks MUCH better". Such a situation exists due to a straightforward reason: you are not the customer. You are the end-user, and that is why you are using the best tool among tools that satisfy the customer's requirements (and the customer is not you).

Such an example also shows why bottoms-up approaches to winning the market seldom work in the enterprise world. I will write another article just around the topic of why people think that the bottom-up approach works.

Things are slightly different in the consumer business, where the end-user is also a customer, integrator altogether. But for the context of this article, we will assume a company - our primary customer.

Integrators

Integrators are departments/teams in charge of taking your product and rolling it out to all the end-users within the org. If you are using a Windows laptop (I hope you are using a Mac) at work, it is not you who installed it there. Windows (of a particular version) was preinstalled for you by integrators (IT department/Ops/Etc).

They also will be on the hook to supporting it, etc. Integrators usually have the most extensive list of requirements, out of which the majority might be critical blockers. Several random examples Your service might be required to:

• have an integration with Active Directory since this is the IAM platform used in the company
• have extensive logging support for the sake of security audit
• support the ability to encrypt end data in a particular way with a user-provided encryption key
• be natively integrated with a specific cloud provider (or the opposite, be on top of Kubernetes)
• have the solution by X date

The most crucial part is the last one (date). Integrators constantly evaluate if they need to start building an in-house solution or trust you (or your competitor) to deliver the solution fast enough. And if they will start building an in-house solution - it is a game over.

The cost of migration from a solution to anything new (even drastically better) is very high and often unclear. I'm sure this statement is something that anyone who has ever migrated any service from one language to another (or even to the new version of the same language) can agree with. You will have to provide a very-very compelling argument why the company needs to invest X millions in migrating your solution instead of investing X millions elsewhere. And investment to migrate from one platform to a reasonably similar platform is almost always not on top of the list for fast-growing companies.

As you can see, when you are evaluating the requirements of the integrators, your main competitor is not "another shiny" startup, your main competitor is an in-house custom solution that will satisfy all the requirements from day zero, while your solution is always a risk that might come up short and late.

End-Users

Finally, let's assume that your product is fully compliant with all the enforced requirements, and integrators have started rolling it out to the initial set of end-users (let's say to 5% of the company). Technically this is what you can call MVP in the enterprise world. This MVP should be barely usable by end-users (but still usable). Integrators will be the middle layer that will be doing the job of collecting all the feedback from the end-users (to whom they are rolling it out) and supplying this feedback back to you. As integrators progress with rolling out the solution, they will give you detailed feedback of requests that you need to address before they can continue rolling out your product to the bigger and bigger user base. Until one day everyone in the company is using it.

Conclusion

The majority of the startups, aiming for any enterprise segment, are trying to build shiny things that are unusable by any big player on the market. They acquire the invisible cost of re-designing everything later on when they have to start thinking about being profitable. Since most of today's startups have a lot of money (via initial funding), they can trick the public by ignoring the customer base that they should be focused on and instead focus directly on end-users. Such a strategy creates a lot of noise but rarely produces anything usable for enterprises.

In a way, ignoring the requirements of the actual customers until the very last minute is not new; this is what we already had in the past with the good old "waterfall" process.