Product as Unveiling

In Greek philosophy, Aletheia (ἀλήθεια) signifies a process of revealing what was hidden. It is commonly translated as ‘truth’, although philosophically it means more than that. I like to bring this concept into product development. The ideal product not as a pre-determined solution but rather an emergent reality that unfolds as we engage with real users, real constraints, and business opportunities.

From this perspective, products are not merely executed in a purely linear way. They are revealed through a dynamic interplay of exploration and iteration. The actions of the product team bring the product into being by uncovering something that is already out there but not yet visible to us.

This is not chaos. Instead, it is a deliberate process of revealing and bringing natural order (κοσμεῖν) to our environment through our actions. 

Inefficient Product Innovation

The goal of a product team is to build great products, not to be efficient. Seeking efficiency for its own sake is ultimately the most inefficient thing you can do. By doing so, you end up with a poor product that solves imagined problems in a boring way. I know that it may seem that not having fully spelled-out requirements and detailed mock-ups slows down progress for a product team, but this is only true at first glance. Allowing ambiguity to linger where it actually is allows the product to take its natural course, rather than an arbitrarily imposed course from someone with highly incomplete information.

Every process and every requirement is based on the assumption that what we are about to deal with is deterministic if we just plan it with enough detail. Of course, this is a fragile approach to an uncertain environment such as innovation. If we operate in an uncertain and complex environment, we need to let the product unfold in the direction it needs to go at each small step it takes in its development. Each team member that is part of building the product is involved in the small-scale decisions that, when compounded, can lead to very different outcomes.

As product builders and innovators, we need to dare to be inefficient. We need to admit our own ignorance in the face of the complexity of what we are dealing with. By admitting this, we realise that there is no better way to build great products than by embracing the chaos and giving the product the space it needs to come into being.

Down with the Requirements

Requirements are often arbitrary constraints imposed on a solution that has yet to take shape. They restrict the team’s ability to make optimal decisions when addressing real technical and design constraints. To avoid this, I prioritise high-level scope and hard constraints, such as budget, time, or laws of physics, over detailed requirements.

While requirements and mockups are often considered standard deliverables for Product Managers, they frequently represent arbitrary decisions that fail to reflect the complex, evolving nature of the product and its ecosystem. These guesses can inadvertently constrain the product’s potential over time—not due to the problem’s inherent nature but because they were prematurely defined. Creating overly detailed requirements and mockups can encourage a ‘just doing my job’ attitude, detracting from the focus on the product as a whole. 

Describing the initial idea in words, the core feeling and problem the team is trying to solve is enough and preferable. The whole team should be inside the same story, around a shared narrative. If the team is aware of the principles behind the idea and understands the grounding centre where everything else should revolve around, they will be able to make all the lower-level decisions necessary to make great products.

Down with the requirements.

Uncertainty Management in Product

The most important activity of a product team is to manage the risk of building the wrong thing while maximising the upside of building the right thing. 

We are all going to build the wrong things eventually. In more uncertain environments, we will probably do so most of the time. But that’s okay. In nature, adapted species survive in their environment because they can afford to lose some individuals that might not be adapted so that the whole can survive. Similarly, we must allow some ideas to fail so that the great ones can emerge.

Once out in the world, ideas take on a life of their own. They are complex. The entire process is non-linear and chaotic. The success of ideas is sensitive to the steps and sequences of actions we take to get there. It’s not just about considering the direct ROI of an idea but also imagining the future possibilities it might unlock. How might the idea unveil itself into new opportunities or even better ideas? Choosing high-upside is not the same as choosing high-impact ones. We don’t really know the impact an idea might have. But with some creativity and foresight, we can anticipate the doors it might open.

Focus more on the effects of ideas and less on their accuracy.

Complexity of Product Teams

Organisms that survive are adapted to the complexity of their environment. Product teams that survive are adapted to the complexity of their business.

In the real world, business problems are complex. They are non-linear (the whole is not the sum of the parts), chaotic (small perturbations in inputs can lead to drastically different outputs), and are path-dependent (the current state is shaped by the journey taken to reach it). Problems within the complex sphere cannot be compartmentalised into tidy disciplines like marketing, design, psychology, or software. They are an intricate mix of all these domains, in no particular order or weight. The only insights we gain are the emergent effects of countless interactions of the parts within the problem’s scope.

Unlike living organisms, product teams are often poorly adapted to the complexity of their environment. For example, these teams are usually divided into Product Management, Design and Engineering, each with their own little farm. While the division seems logical, it only marginally improves productivity at the cost of innovation and meaningful solutions.

The adapted product team has no rigid roles. Everyone is involved (in various degrees) with all the facets of the problem. This adapted system uses the particular skills of its members to survive without abstracting away the complexity. Members of adapted teams don’t view their peers as black boxes but as an extension of themselves.

Adapted product teams survive through the innovation they create; specialist product teams just do their job.

Prioritizing is easy, really.

One of the easiest things in product development is prioritizing. It’s one of the most important and, as such, people tend to overcomplicate it. Much has been written and theorised about it at the expense of actually being useful. Let’s simplify. You can be in one of two states: either you have a task that is clearly the thing to be done next and everyone in the team agrees, or you are undecided between $N$ options about what to do next.

What really matters is deciding what to do next. If you are uncertain what to do in 6 months, don’t decide; keep the options open. Therefore, if the product team all agrees on what is the right thing to do now, you have that part solved. If you are uncertain amongst several options on what to do next, then you and your team haven’t explored the product problem deep enough, and you are still navigating on the surface level where solutions look about the same (given that you are working with a large enough scope to find interesting problems to solve). If you still can’t decide, then just pick one. If after investing some time on a problem there is not a clear winner, then there is still too much uncertainty, and it can’t be planned out without execution, so you need some execution. Solved.

One could argue now: But how do we determine what is the right thing to do? Well, that’s taste.