¿Eres creador de contenido visual?
Empieza aquí

Product Thinkers: How to Design and Lay the Groundwork for your Tech Team

The greatest necessity of a cutting-edge technology startup is to release impact in the shortest possible time. There is no way to know what could have value for the end-user until you release a product that verifies our initial analysis and forecasts. 

At BOOM, the definition of our “product” varies - it can be a feature, a new user flow, or an app with well-defined boundaries. In each of these cases, the process leading to its conception and its consequent implementation requires time, energy, and total participation from all the stakeholders involved in each phase.

Research, ideation, and creation require a great deal of energy from a Product Manager. And because these steps enable the creation of a great product, is the role of a PM about writing stories or about committing to imagining, verifying, and refining the future ahead of time? 

Time is the most important resource and we never have enough of it. This is precisely why PMs do not deal with "bureaucracy" here. They don't write stories with a grueling list of requirements to be revised and rewritten depending on unexpected events or missed requirements. Instead, a PM’s job is about defining the big picture and the MVPs of the next projects ahead of time, as well as iterating them to give the tech team a clear vision of what’s expected.  

How do we apply these principles at BOOM?
For us, it all stems from one question: considering the company vision, what problem do we want to solve for our users? What are the main pain points will they have to face in the coming years?

From this question comes the first research level that involves the entire product team and is divided into focus groups, product discovery, interviews, and competitive analysis, to identify high-level projects to invest in. All of these projects are then fed into a roadmap that we call the Product Strategy Roadmap (PSR). The PSR - which by definition is not immutable (on the contrary!) - adopts names that are clear to everyone in the company. Remember, everyone must be able to understand what we want to invest in without digging too deep into the details! 

So how do we consolidate different projects?
This is where our product thinkers become fundamental.

Considering the various projects in the PSR - which we call strategies - the PMs begin to rigorously explore the terrain by reiterating the steps mentioned above (focus-groups, product discovery, interviews, competitive analysis, surveys, or inventing new techniques but with a much higher level of detail). Decisions depend on the quality but also the quantity of data and insights available. 

What happens after that?
Each PM is responsible for defining a memo by providing a BIG-Picture of the project and slicing it into many MVPs, which will confirm or validate the solution in the shortest possible time.

For each of these projects, we define a metric known as a proxy metric, which will confirm the progress of the project. Remember, with us an MVP is like an experiment: we believe in something, we bet on it and then we check if our hypotheses are correct. We are scientists who operate in an unknown environment, where the presumption of knowledge is our greatest enemy.

For each of these projects, we define a roadmap, known as a POD-Roadmap, which connects each of them to those defined in the PSR. We call this process bucket creation.

And what happens if a strategy in the PSR runs out of linked sub-projects?
In those cases, we evaluate why and determine if the project defined in the RDP makes sense or not. This is a fluid process where nothing is written forever and everything can change!

So once we’ve established what needs to be done, how can the tech team make it a reality? 
At that point, an epic is written for each MVP, which defines the final result expected. Each epic is completed with wireframes and mockups in which UI and interactions are defined with absolute precision. The product design team’s role is fundamental, as is their role in improving the solution itself. 

At that point, the tech team (also involved in the previous discovery part) starts drafting the stories that connect to the epics, which provides T-shirt sizes and more precise estimates, as part of their responsibility for the entire solution. 

This process has allowed us to keep the product team focused on value for the end-user without dwelling on the not-so-agile bureaucracy, and to distribute ownership of the result across all teams. In fact, we do not follow the idea that "product gives requirements" and "tech performs" but rather "product thinks about what to do and why" and "tech proposes the best technological strategy to do it". It might seem redundant to reiterate it, but trust us, it isn’t!

We have little time and a lot to do, so it’s important to improve and do better with each project, isn’t it?

Find out more about BOOM's product!

Transformación visual en un instante