User Driven Development: The Lean startup principles implemented in enterprise software development

User driven development (UDD or User-Centered Design according to Wikipedia) is not really a set of methodologies but  a philosophy or paradigm that a development team can follow. In today’s world, where interacting with technology becoming part of more and more everyday tasks, the single most important factor that will make a service successful, is the end user satisfaction. This is mainly true for products that people would want to use and not for ones they have to use. An example of the latter is large scale enterprise systems which are built to serve a specific function, based on already known tasks.

Unlike consumer software, enterprise products don’t have to strive for consumer satisfaction in order to grow. The requirements are usually very extensive and mainly concern security, usability, maintainability etc. If UDD is used, these requirements will again be present, but only implemented when needed. Resources can be saved by not spending unnecessary money in procuring expensive software solutions such as Database Management Systems.

In this post I’ll talk about what UDD is, the processes involved and why even enterprise development teams should incorporate its philosophies in their daily processes.

The Process

The basis of UDD is pretty self-explanatory from its name. UDD’s main goal is not to just always make decisions based on user requirements, but also involve the user in the development cycle from the starting point. UDD incorporates the principles of the Lean startup with the methodologies of Agile development. The Lean startup is a method proposed by Eric Ries and is based on Lean manufacturing. A quick Wikipedia check will tell you that

 It’s a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination.

Ries translated that idea to software startups. In order to eliminate any wasteful practices, lean startups employ the following techniques:

According to the Lean methodology, a startup has to first create a Minimum Viable Product (MVP). A MVP is the first version of a new product that implements the most basic functionality that can be shown to the customer as quickly as possible and receive feedback. This helps clear up early assumptions and hypotheses so that the team has a firmer foundation to build on. Once this is ready, the team gets constant feedback from the users in order to start Continuous deployment on the product. Continuous deployment also ensures that user feedback will be given early for new features. Once the product grows in complexity, A/B testing is used against groups of users, to determine which features bring more value to the user.  This continuous process is also known as build – measure – learn.

A vital part of this process is that the developer does not rely on feedback acquired through questionnaires or collected by a different team. The developers need to demo the product in person and then collect information while the user is trying it out. This is especially true in the early stages of development, during which tools like Google analytics don’t provide any meaningful data from a handful of users. UDD usually employs Agile practices but, just like features, practices that are deemed to be wasteful are simply scrapped or replaced with more effortless alternatives.

If you’re interested in seeing UDD in practice in its purest form, check this video out where a team of developers iteratively create an app right in front of the users:

 Why UDD?

It’s easy to find motivations for using UDD in a startup. Startups usually lack extensive funding, specific direction and a user base. The process of UDD helps with overcoming the early hump of choosing direction, building useful software with minimum funds and satisfying the user base in order to help it grow. These concerns however are not something that a team building enterprise software will have to worry about. Nonetheless, there are a few advantages that can be gained by building enterprise software following UDD practices.

We will use Ernie Miller’s article as an example of UDD implemented on an enterprise software. ( In his article, Miller talks about how he built a replacement software for his company’s trouble ticketing system.  The author followed the process of closely interacting with the software’s users in order to get feedback on the necessary improvements needed. One of the first major changes in the ticketing application, was the removal of all ticket states except for resolved and unresolved. This was done because he realized that all other tickets states usually ended up never changing and remaining active in the database without anyone caring for them. This is a perfect example of wasteful features that can be eliminated.

According to Miller, the first version of the software served the most basic operations that were needed, and was only rolled out to a few employees in order to receive feedback. Within the years, the project was used by more and more employees and was changed radically according to focus group insights and word-of-mouth comments. Once again, this shows the basics of UDD in action. The interesting part of the article comes when the writer describes how upper management handled the news of a custom made system. They were not very happy about it. Miller describes their meetings as “speaking two different languages”, with him trying to explain the user benefits and the managers looking at the solution from a bottom-up view, concerned about database designs etc.

So why would a large company want to use UDD in the process of building their enterprise software?

  • Wasted resources are bad for everyone. It might be more essential for startups to make efficient use of their budget, but just because a team has more funds available, does not mean that more funds should be wasted. Resources also mean man-hours spent on a software. According to some metrics (, up to 45% of software features might never be used and 35% is rarely/sometimes used. This means only 20% of features are always/often used by users. This a huge waste of time by developers that could better be spent improving essential features instead of maintaining and useless ones.
  • The users still matter. The system’s success might not be based on the number of its users, since that number is pre-determined. But why would a company want its employees to use a cumbersome system filled with clutter, instead of something that might make more sense to them, and makes the process more pleasant, even if some minor features are missing (in the beginning; they could be implemented later on if considered to be important).
  • Face time with users. When building an enterprise system, or any other system for that matter, in a large group, developers often do not get any face-to-face time with their end users. In projects like these, it’s easy to get lost in the technical matters that are passed down from managers and completely forget the  conversation about the end-user. A user is not just a set of requirements and features, but a person who might just even have insight that the developer could have never thought of. Spending time with your end-user is a great practice for understanding their point of view in any product.
  • Learning new technologies. This might be more of a perk than an overall advantage of UDD. But if a developer has to solve a problem without pre-determined tools, the possibilities are endless. Maybe the team will finally get rid of the expensive (and often considered outdated) solution of using SQL server just because the company is partnered with Microsoft. The developer might discover that a NoSQL database can yield much better performance results for the required task and gain new skills in implementing the database.

Implementing UDD

So if we assume that the early statements is true, and companies building enterprise software should employ UDD, why can’t an enterprise software strive for user satisfaction as its main goal? As mentioned before, one of the problems is the lengthy list of functional requirements that an enterprise system needs to adhere to.  Another obstacle is the large scale of users the system will need to accommodate from the get-go. Also, since enterprise systems are usually necessary for the user’s daily routine, there is little room for failures.

However, some of the characteristics of enterprise software development can also be used in favor of the process.

  • User knowledge. Startups fight for the product-market fit. Their product is often something users don’t even know they need. Enterprise software on the contrary has to perform specific tasks. This can be used in favour of the feedback the developers receive. The user can compare and contrast with pre-existing solutions and offer valuable input on what they’d like to see from a product before it is even built.
  • Domain experience. This can be a double-sided coin. It’s hard for developers that have been working on the same product for years to suddenly think outside the box. But at the same time, experience is a powerful tool when it comes to figuring out a technical implementation to address a user-requested feature.
  • Funding. If UDD is used correctly, the large funding that a company may have for a specific product, can deliver a significantly more successful product than the result of more conservative methodologies.
  • Testing. Though one of the fundamentals of continuous deployment is to often build first, fix later, this is not necessary. Especially if a team has available testers, their input can be invaluable by automating processes that can ensure new features do not raise bugs. In other words Test-Driven Development can be utilized as a facilitator for UDD.


Agile methodologies are a great way of organizing a team. But UDD goes a step further by going directly to the user instead of building User Stories out of thin air. Large enterprise software companies might have been used to the way things are done, often slow and monotonous. But it is feasible to change this. Slowly and iteratively, even the most cumbersome systems can become a pleasure to use and get rid of the clutter that only makes a user’s experience worse and offers nothing to the overall picture.


Some more info on UDD and Lean principles:

Ernie Miller’s article: