Go faster by investing time on Research and Scope

This article was originally posted in the Ontruck Product blog.

Some months ago we shared the product process we follow at Ontruck. We do many things differently than most of the tech companies, one of those is how our Product & Tech teams spend their time.

The first thing you may notice is that we spend less time on the Design and Build phase. The second is that we spend more time on Research and Scope. Why do we work like this? Does this produce better outcomes?

I found this quote on an internal doc from Atomico which reflects perfectly our philosophy (Atomico invested $10M at Ontruck last May).

“The more work expected, or complexity behind an idea, the more validation one should pursue before implementing it” – Atomico

Research, Diverge and Scope

Most companies don’t do these phases. Stakeholders ask for the solution; the PM writes the user stories; the designer draws the interface, and the engineers code them.

At Ontruck we focus on problems, not on solutions. The PM prioritizes the technology raised by the stakeholders. Then, the Product Designer and the Software Engineers spend time researching and diverging.

The goal is to understand the problem and check its implications with other projects. It’s also important to set the vision for that topic, as every future iteration should follow it. The time spent here reduces the probability of:

• doing projects which aren’t relevant enough (we kill them at research phase)
• doing projects we don’t have enough information (we kill them at research phase)
• doing the obvious tech solution instead of thinking outside the box
• doing a specific solution for that scenario instead of looking at the big picture

Once the team knows the whole context, we are ready to decide the solution. At this moment we haven’t drawn nor coded anything. We try to reduce the scope and phase as much as possible; we ask ourselves: What can we validate in one or two weeks?

Design, User Test and Build

With the defined scope, the Product Designer designs the interface and interactions. The Software Engineers design the integration between systems (database, APIs, dependencies, conflicts with other projects).

There is a lot of communication between them to make sure they have covered all scenarios. At any moment they can keep reducing the scope and phasing the project. Designing and coding are expensive, so the aim is only to build what we have validated.

The user tests go in that direction. It’s much faster to test designs with five clients and iterate them rather than coding and iterate them once the team has already moved on to another project. It helps a lot if Software Engineers come to the user testing because they notice the user problems, so they pay particular attention when coding the solution.

Only after we have validated the designs with users, we start coding the solution. As we have spent time reducing the scope and defining all the flows, we cut a lot the back-and-forth on this phase (change of requirements, forgotten user flows, missed texts, lack of integration with another system, merging conflicts, etc.).

Go faster by doing less

In the end, this is the same philosophy as Less is more. The more you understand a problem, the simplest the solution will be. Projects get overcomplicated when the team wants to cover a lot because they aren’t sure about all scenarios.

Start with something small, validate it and iterate. Learn as fast as you can. That’s our mission in startups and life.