The theory of everything: How to build products users love…

… and how to build an organisation that is capable of building products users love?

In the last 3 months, I was thinking a lot about what makes an organisation and product successful. I did not have a simple answer:

  • Focusing the users and delivering value.
  • Fast, validated learning.
  • Innovation.
  • Team empowerment and self-organisation.
  • Common values.
  • Trust and leadership.

Now I think that maybe one of the biggest leaders in history is right, and there is a human quality that guarantees all others, and eventually, success.

Productivity vs value

Some may argue that productivity is the key to success. However, productivity is beneficial only if you produce value for our customers, but if it is not so, the result is merely a huge pile of worthless features and oversized code-base that has to be maintained for a long time: the income will be lower, while the costs of maintenance and future developments will be higher.

Therefore, instead of focusing primarily on being productive, focus on delivering value. I am not saying that productivity or efficiency is not important. It is! But it shall not be measured by the number of code-lines delivered per day; efficiency shall be measured by the value it delivers to its users.

How do you know that the feature that you are working on will really help your users and solve their problems? Can you back your decisions with data?

Fast, validated learning

Lean principles combined with validated learning techniques give us guidance on evaluating and refining the features:

  • Users and the development teams shall be closely connected. Development teams shall have access to the information regarding the users, their concerns, behaviour, pain points.
  • Feature ideas must be validated as early as possible.
  • The validation shall be done against a predefined goal and metric that represent the goal.
  • If a feature which is not validated, and not proved to be valuable for the users, it shall not go into production and must be removed from the code.
  • Subjective judgment must be excluded from the decision process, decisions must be made based on data. In case of disagreement, either the data or the decision methodology shall be re-considered.

(image source: The Lean Startup Methodology)

Several techniques are available that allow us to validate a feature idea and refine it, if necessary.

Prototype-driven user testing is one of those validation techniques. Implementing a testable prototype shall not take longer than a few hours, or 1 or 2 days maximum. There are excellent quick prototyping tools available, but paper prototypes can also give us the necessary early feedback and insight. Prototyping can be multi-phase, you can start with a static image or a paper prototype, and enhance the prototype incrementally. In each increment the prototype can be tested, and based on the metric you can enhance or alter the prototype, or abandon the idea.

You can find the real-life “representations” of our personas, and depending on the market and the product you can give them demos regularly (e.g. at least once per 2 months), or ideally, you can collaborate with them on a daily basis.

You may release the new feature to only a small proportion of your users (e.g. 1%) and gather data during a test period. Based on the data you may decide to make the new feature generally available, alter it, or completely delete it from the product or service.

Advertisements can also be used for testing. For example, you can start a Google AdWords campaign, and measure revenue increase. If it is smaller than the advertisement costs, you shall consider removing the feature since it does not provide enough value for the users but increases our maintenance and development costs.

Different domains require different techniques, and not all techniques can be reasonably applied in every domain; however, there is a common principle: the more frequently you validate the product, the faster you can learn and produce value.

How many features did you have to drop or change in the last 12 months? If the answer is “none”, then most probably you have not learned anything during this period.


Traditionally, the roles of product management and engineering are well separated: the product management (team) defines the product roadmap and the upcoming features, while the engineering organisation implements the roadmap items. What a waste of innovation potential!

In order to nourish the culture of innovation teams must have easy access to information such as business goals, customer situation, summaries of user interviews (exposing user behaviour and pain points), and feature usage statistics. If product management wants to endorse innovation, they have to share these pieces of information regularly (e.g. once per month), organise open forums with engineers where they can ask questions, and let the engineers use the data to gain insights and, ultimately, design new features.

Any obstacle that binds the implementation of an idea to management approval kills innovation. Within a well-defined framework, engineers shall be given the freedom to implement their ideas. For example, to start the implementation it has to be sold to other engineers who would participate in the development, and only limited time can be spent on the implementation (e.g. a week-long hackathon).

In a “non-greenfield” market, there are several companies that have already developed a new feature or product which is on our roadmap. If that company is available for acquisition, shall we buy it, or shall we develop the product ourselves? Among others, weakening innovation culture is a factor that the buyer shall consider: although by acquisition we buy competence, market share, revenue, we also lose a chance to learn, we don’t gain experience from experimentations, and our engineers may eventually lose motivation.

It is easy to check if your company really nurtures innovation culture: just think about how many features did your teams contribute to your roadmap in the last 12 months!

It is also easy to assess, how innovative your organisation is. How many features did you deliver in the last 12 months that was not requested by your customers? If the answer is none, then, at best, you just react to your customers’ requests.

Team empowerment and self-organisation

Micro-management is one of the biggest enemies of innovation and performance. It exhibits lack of trust and weakens the teams’ ownership of the product they are building. Micro-management trains engineers to follow orders and discourages them to speak up.

(image source: Dilbert by Scott Adams)

A team will never reach its performance potential if it constantly relies on management decisions, requires coordination from the leadership team to collaborate with other teams in the same project on a daily basis, and cannot reflect on and improve their own processes. Therefore, empowerment and self-organisation are essential to building high-performing, truly innovative teams. Consequently, instead of micro-management, leaders should rather facilitate the teams’ work and remove impediments.

Truly empowered teams are involved in such management decisions that are impacting them: like decisions about release dates, organisational changes, or even acquisitions.

Can you, as a leader, go for a 2 weeks long vacation so that you don’t have to read your mails and call-in for meetings to make decisions regarding the regular work of your teams? If the answer is no, you made yourself indispensable, which is an obvious risk for your company.

Culture and values

To get rid of the indispensability, as a first step, you should identify your organisation’s core values. What is important for you, what do you care about? What do you consider when you make decisions? What drives you? What is your mission? The answers you give (along with the data) determine most of the decisions you make.

Identify and communicate the organisational values regularly, use them in your everyday work, refer to the values when you explain the motivation behind your decisions.

Have events regularly (e.g. once a week, but at least once a month), when you talk about values, strategy, and the latest news. Let your engineers dissent and ask tough questions, and consider their opinion.

I often heard managers declare that their goal is to keep the organisation flat. A flat organisation, however, shall not be the ultimate goal. As a matter of fact, a flat organisation is an inevitable consequence of the identification, communication, understanding, and acceptance of your core values. But if flatness is your only goal, and your team(s) don’t have shared values in which they truly believe, you will face a chaotic, uncoordinated and low-performing group of individuals.

Learning from mistakes

It is often a taboo to talk about mistakes. A failed product? Don’t mention it! Unnecessary acquisition? We are in an unpleasant situation. The new feature is hardly used by anyone? We did a great job anyway. The management may think that open a discussion about mistakes would be a sign of weakness and would ruin morale. I deem that the opposite is true.

An organisation can learn a lot from its successes, but we can learn way more from our mistakes.

Trust, leadership…

Heavy-weight processes, micro-management, the culture of information hoarding, and the exclusion of teams from the decisions that are impacting them are clear signs of lack of trust. However, without trust, we cannot build a streamlined, innovative, and high-performing organisation. According to Stanley A. McChrystal

A leader isn’t good because they are right, they are good because they are willing to learn and to trust.

A leader does not only “find good people”, but also ”let them do their own job”, protects them, and cannot be bent by old-fashioned incumbents.

…and courage

Finally, there is a human quality which is an essential part of the character of a true leader: courage. As one of the biggest leaders in history, Sir Winston Churchill, stated,

Courage is rightly esteemed the first of human qualities because it is the quality that guarantees all others.


  1. Mary Poppendieck, Tom Poppendieck, “Lean Software Development: An Agile Toolkit”, Addison-Wesley Professional, ISBN: 0–321–15078–3
  2. Donald G. Reinertsen, “The Principles of Product Development Flow: Second Generation Lean Product Development”, ISBN: 978–1935401001
  3. Eric Ries, “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses”, ISBN: 978–0307887894
  4. Eric Schmidt, Jonathan Rosenberg, “How Google Works”, ISBN: 978–1455582341
  5. Gerald M. Weinberg , “The Psychology of Computer Programming: Silver Anniversary Edition”, ISBN: 978–0–932633–42–2
  6. Marty Cagan, “Inspired: How to Create Products Customers Love”, ISBN: 978–0981690407

(The original version of this post was published on December 23, 2014.)

Liked this post?

If you enjoyed this post, please help out your friends with a *clap* or a share.