“How should we get started?” is a question we got used to listening to.

“Let’s find out together!” is the answer we got used to answering.

There’s no magic recipe in Product Development. Each business strives in different circumstances, and quality is about making the best out of each context. That’s why, when potential clients knock on Pixelmatters’ door and want to start fast, they hear many questions from us first.

Without understanding the business and the current Product, going fast will lead to a dead-end street. For a product to succeed, we should play for the long run by starting small and iterating quickly. That’s why Phase 0 is essential.

What happens in Phase 0?

From a few days to a couple of months, it will role out a bit like a Sherlock Holmes movie. There’s a mystery to solve — where should we start here?

To determine what should be worked on first, we begin by assigning a smaller cross-functional team consisting of a Product Owner, a Designer, and an Engineer - probably constituted by senior people across the company - that may or may not be a part of the team later on. Depending on the context, this smaller cross-functional team constitution may vary, and we may have other senior roles involved for a short period of time. The rest of the team joins later once there’s a defined path for what’s ahead in the coming weeks/months — for example, the remaining Engineers that were not a part of Phase 0.

In parallel to determining priorities with this team, we kick off another part of Phase 0 — clarifying the path and building alignment with the client. The rest of the team that will build the Product - isn’t involved at this point because of efficiency - the goal is to onboard them once the plan is clearer. After all, Sherlock Holmes only has Watson by his side the entire time for a reason - too many people would only slow him down in such an exploratory phase.

As the purpose of Phase 0 is to build alignment on what can be a potential MVP or initial iteration, the first step is to understand the following:

• The business model;

• The current Product (if any);

• Previous work done on top of the Product;

• The main goals for the first months of the collaboration (and why those are the priority).

At this stage, the Product Owner often leads the efforts in close collaboration with peers from Design and Engineering as they’re still identifying the main opportunities and planning the initial requirements. It’s also a period of divergence where multiple ideas and alternatives are discussed. After all, this is a collaboration, and clients expect to hear our advice on how to move forward! 🚀

Once there is a high-level understanding of the business, the Product, and the main goals are identified, it’s time to get our hands dirty and start converging.

From first conversations to groundwork

This is where Design and Engineering take over, collaborating with each other and with the Product as we dig deeper into what’s needed before the rest of the team that will be a part of the project joins.

The work we do here can take many shapes and forms depending on what comes out of the first conversations - the most common scenarios are:

1. The client knows the direction and the potential solutions, and Phase 0 is used to craft a couple of ways to get there;

2. The client doesn’t know the direction or potential solutions but knows the problem at hand and needs our help during Phase 0.

We might adapt the depth and focus of our work depending on the scenario, but our necessity to understand the user needs from a technological standpoint doesn’t change.

A few exercises we can conduct on the Design side:

• Personas - Build the user personas by analyzing internal documentation provided by the client or by interviewing customers.

• Customer Journeys - Craft the most helpful customer journey, considering the initial features we’ll work on.

• Crazy 8s - Once the client identifies a problem, the team gathers around and starts brainstorming potential solutions to solve it - the primary outcomes are discussed with the client, and one idea can serve as the starting point to get things going.

• Wireframes - If there’s a specific flow in mind, this is also a good time to draft a set of wireframes to materialize some thoughts.

‍On the Engineering side, the focus relies mainly on making the first critical decisions to get things going:

• Code Analysis - If there’s a current product in place, we conduct a thorough audit to identify any immediate changes and know the foundations on which we’ll start building the code.

• Architecture & Infrastructure - If not yet in place, decisions related to the Product’s architecture & infrastructure are essential to start with. This gives the rest of the Engineering crew a common understanding of the guidelines everyone should follow to ensure the Product’s scalability, consistency, and good practices.

• Tech Stack proposal - If there’s no product already built or we’re starting from scratch, defining a tech stack is a good step, to begin with. This can lead to a quick proof of concept to validate a few assumptions in the Product’s context, even though, at this stage, this only unblocks a product or design decision.

Conclusion

The initial discovery stage is crucial to success in a Sherlock Holmes mystery. The same applies to Product Development. Phase 0 gives us the necessary context to fully understand the Product, align expectations, and define the initial working points. Investing in this Phase 0 will allow us to position ourselves better to help you solve the essential mysteries that stand in the way of growing your business.