I was the first product hire at Nuvocargo. Right now, the org is 5 PMs, 4 designers, and a data team with 3 people. We have business counterparts that represent Demand, Supply, Marketplace, and Finance. There’s marketing, enablement, and tech support. The engineering team is about 25 people organized in about 4 squads. 

We’re a cross-border organization and have a technical team in Mexico. The craft of product is in a different stage there. The team there was used to handoffs and a more waterfall-style process. My intent in building this process doc was to create an output that will help teams work together in a way that will help people understand their responsibilities. I also wanted to help make sure that as we got more clarity on a problem, we were communicating out these learnings.

At first glance, this process may seem heavier weight than other product development processes, but that reflects the complexity and risk of our business. When you think about product decisions and complexity, if your product consumer and digital-only, you have the least complexity. If you get shown the wrong video on TikTok, it’s not that big of a deal. Something with physical goods has much bigger ramifications. 

You also need to think through whether you’re making a one-way decision and the implications of the one-way decision? If you’re doing things tied to the physical world or things that have a lot of one-way decisions, there aren’t good product development processes for that. This process helps build more confidence for very consequential, hard-to-reverse decisions. 

The other part of the complexity this process accounts for is organizational complexity. If my offering won’t be fully launched until customers on the ground understand the implementation, it is a lot more complex. More steps of planning and review are needed to have a successful launch.

We’ve had three iterations of this process since launching it. The last mile of aligning operations and customer deployment has been challenging. We weren’t engaging on GTM early enough in the process. Most of our PMs were used to shipping and being done—maybe they’d send an email to customers about the launch. With this iteration of the process, we’ve been able to frontload a lot of the alignment and getting rid of the ambiguity around GTM. 

For future iterations, I want to look at if there are ways to speed up or simplify the process for things with less ambiguity. Are there ways we can get quicker alignment on the decisions? How can we make the process go faster when we have confidence or don’t have one-way doors for decisions? Once we solidify more of the foundational pieces of the business, I think we’ll see more projects that can have simpler processes.

There’s always a PM, Designer, and Engineer from P0 of the process. They should are having really healthy early conversations with all the different teams as we start considering options to build. Depending on the type of problem, in P1 of the process, the design team may need to do more research into why the problem is happening (e.g., is it something with the current design?). Before we write all the details of how the solution will work, the P1 will have all the options.

You don’t want the whole squad at the beginning dealing with the ambiguity. I think of this like you have a core team of explorers at the beginning. As you get more clarity around the problem you’re trying to solve, you expand the team to include the operators. It feels more like collaboration and less like handoffs.

We have a one-year roadmap and set objectives quarterly. We then organize our work in biweekly sprints. The Phase 0 step has value because sometimes, as we’re beginning to execute on one of the ideas we’ve already come up with in annual or quarterly planning, we end up discovering something else. Phase 0 is an escape valve; it helps you discover if there are emerging opportunities. 

We typically try to frontload the projects that are aligned with the annual company strategy. We had a six-week customer research phase in December to prepare. Typically we do that big customer discovery piece twice a year. As a result, our Phase 0s have been more to align on the success criteria of a project versus whether to do the project. 

When you have an org where you have to drive both product success and operational success, it’s really key to align on success before. Before we had implemented this process, we would show people prototypes and they would be like “oh, this isn’t solving the problem.”

We don’t need a formal review meeting for every phase of the process, but we tend to like them for P2 so people and customers can review a prototype.

One of the pieces we added to the process was the post-launch piece. We found that teams would just jump to the next thing and report out results only in a limited way or out of context. We added the post-launch step and it’s creating a lot more accountability. Teams have to address whether they accomplished what they said they would in P0.

A good review looks like people are aligned and understand the tradeoffs and choices we’re making—it’s not the same as agreement or consensus. Success is named in the “activities” section of each step of the process; if we answer the questions, it’s successful. It’s okay for the answer to “will we work on this?” to be “no.”

This may seem really time intensive, but which is cheaper: to find out that something is not viable after you built it, or to find that out in an earlier conversation? I think the easiest way to test an idea first is going to be building the lightest weight prototype, or having conversations and getting reactions from people. If you can’t pass that and you go and build a a final product, you’re wasting your time. 

This process isn’t about making people jump through hoops for no reason. Even in simpler organizations, people with have different ideas of what success looks like. This process is really just giving teams a template that they can modify. This can be choose-your-own-adventure.

Part of this process is making sure that the data team is involved early to make sure we can measure anything that’s released. We make sure the process starts with how we’re going to measure success.

The document should reflect discussions and decisions the teams have already been making. Teams should be collaborating on these questions before creating the doc; this doc shouldn’t be the first time a key stakeholder is hearing about the project. 

Typically if the document is done well, you may never even need a review meeting. We get together if there are things that are faster to hash out in 30-45 minutes in person (e.g., we need a tie break, we need to discuss how we will weigh different priorities).

Reviews can be optional depending on the stage of the project and the level of alignment.

We want to make sure the team is thinking expansively, especially if it’s going to be a big change. For something that’s like a build vs buy decision, this process has helped us uncover very important architectural decisions (engineering, design system). The process shepherds these decisions.

Different parts of the org may disagree on how these axes are prioritized, but that’s why we separate P0 and P1 of the process. If you get people to align on what success looks like and what metrics you’re going to move in P0, it allows the team to pick the solution that’s best suited to solve the problem. There may be tradeoffs and downsides, but if we’re aligned on trying to drive for business impact, then it just becomes a negotiation around how we’re going to do it.

Deployment complexity is a really common axis we need to consider. For instance, if we choose one implementation direction, it might be really easy to build, but it will take another six months to actually deploy on the customer side. That’s why it’s so important to pull in our operational partners at this stage.

For things that are lightweight, we’ll do P1 reviews async.

In P1, a successful review looks like alignment on a path being the right choice and the team understanding the downsides and pros of that approach.

Most of the feedback I give at this stage is on the experience and business metrics. I care a lot about how you measure success and how you think about the users—what does it look like if they’re happy? Oftentimes the people on the team are the experts on the specific customer or problem they’re solving; I’m just pressure testing on how it meets the success criteria. 

In terms of feedback, I’ll call out things that feel clunky or confusing, but instead of telling the team what to do, I lay out how to think about things. I sometimes don’t know which of two options will be best, but I push the team to learn by shipping—what is the thing that will help us learn the fastest? My job as a leader is to bring clarity into decision making, not to make the decisions for the team because otherwise, I’m throwing away all of the expertise and research time the team has already put in.

Something that has happened a few times is that as Product Leader, sometimes I can’t say which one of two solutions is going to be best. In those cases, the thing I end up pushing on is which solution will allow us to validate things faster and get feedback from users. I push the team a lot to actually learn from shipping versus trying to beat a dead horse discussing it in meetings. There are some things that you can’t just think really hard about and get right. The tie breaker is going to be the user. It’s not going to be us spending three weeks discussing a project in the abstract.

For this phase, “success” is more like completing the checklist: have we talked to all the right people? This phase can happen while eng is building.

Nicholas Simmons

Lilibeth Bustos

Marc Personick

Anaid Chacon

The product development process at Nuvocargo includes several layers of review to de-risk complex initiatives. Steps can be condensed for simpler projects with less operational complexity.

Product Development Process and Reviews at 

At the highest level, the goal of this process is to determine if a project should be undertaken, what requirements it must fulfill to be successful, and how to learn from its launch. The output of these reviews informs the engineering, design, and go-to-market (operational, deployment, and marketing) work by clarifying what should be built and why, dramatically increasing the likelihood that the work is impactful. The engineering, design, and go-to-market work is mapped for each phase, 

this process serves to create a cross-functional collaboration motion

 that Product orchestrates but still allows for other functions to own their craft-specific deliverables (e.g. design spec, engineering architecture reviews).

✅ This process ensures that business and technical teams are aligned on priorities and what that looks like.

✅ Have formal reviews that inform the engineering and design work by clarifying what should be built and why, maximizing shared context and opportunities to collaborate.

✅ Design and engineering teams should collaborate using their processes and best practices.

📌 While the process of creating engineering and design specs is connected to the Product Development Process, 

separate engineering specs and design deliverables

 should be produced by engineering and design leadership as part of different steps of this process.

📌 While many projects are derived from our roadmap, it is possible that this process will present a new opportunity to replace a project already in process.

We use the DACI framework to make effective & efficient group decisions during the Product Development Process.

The DACI framework aims to define roles and responsibilities for each team to clarify how best to work together while avoiding redundancy and building an efficient organization. In the product process it looks as follows:

Eng and Design leadership have heavy input

Functional leaders have heavy input for internal tools

: Design IC, TL, EM, Marketing, Ops / Sales leads, Support

Select eng or design ICs can be brought in starting on Phase 1 at the discretion of eng leads.

: EPDM (through meeting notes), affected internal functions

Depending on the project's complexity, the process can have up to four phases:

Phase 0 What problem or opportunity could we address? Why is it important?

Phase 1 What’s the best possible way we could solve this problem or realize the opportunity?

Post-Launch How well did it perform? What did we learn from it?

We dont need a formal review meeting for every phase

One of the pieces we added to the process

The doc is shared as pre-reading with everyone working on the project and all potential customers

A subset of those working on the project and potential customers meet to discuss

Product Leadership is the final arbiter of whether a project has been approved to proceed to the next phase or has completed the last phase that will be reviewed for the project

The Product Review doc should be sent out to the attendees at least 

 read the document before starting the discussion.

If the phase is approved, send an email out to everyone working on the project, all potential customers, and EPDM-meeting-notes@/ appropriate slack channel

This email contains the documentation and notes from the review

 can be merged when we have high alignment on the sequence / relevance of project at the moment. For example, in the a recent project we have aligned in a sequence to build so we don’t need to answer “why now” for every module, and we can merge success criteria definition, problem alignment, and options to solve in a single review (P0/P1). Phases can be merged when the problem to solve is less ambiguous or low risk (i.e. easily reversible decisions), this typically leads to a faster implementation.

 could be merged with P2, but it may actually delay implementation so generally it’s better to get the P2 ironed out and for Product + leads to work on the rollout plan (P3) while eng implements the P2 requirements.

It is recommended that we keep separate the “what is the problem and what are our options” (phase 0 and 1) from “how will the solution work” (phase 2) to make sure there is clarity on the problem and we’re not just jumping to the first solution that comes to mind. Even when phases are be merged, all the questions should still be answered to uncover potential unknowns or misalignments. It’s generally cheaper to uncover those issues during research and definition than after building a specific solution and testing it.

With that, a sped up process would look like this:

Combined Phase 0 and Phase 1 — Clear problem statement, success metrics and recommended option

Combined Phase 2 and Phase 3 — Solution design (prototype, mocks, tech spec) and high-level launch plan

Launch will happen after the solution is deployed, so this is always a separate step.

Each phase's timeframe highly depends on the size and type of project. On average, going through all the phases (from P0 to Launch) for a project will take one month.

 Note that his includes user research, discovery work, high-level prototyping, and engineering reviews. Smaller changes (e.g. bugs or enhancements) have a different budget and different prioritization process.

Phase 0 - What problem or opportunity could we address? Why is it important?

This phase exists to determine whether the project is worth undertaking. 

A key piece of this is clearly defining what success would look like for this project.

 This phase contains no potential options for how to address the problem or opportunity. Use data, research, and output from conversations with involved teams where possible to back up any assertions and test hypotheses.

✅ Hypothesize top causes of this problem

✅ What outcome do we hope to achieve for the target user?

✅ What criteria will we use to measure success?

During Phase 0 you will collaborate with a number of different stakeholders across the team. The table below illustrators who is the driver, approver, collaborator, and informed party of each question we will answer during this phase.

The doc should address each of these questions:

What are the problems or opportunities being addressed? 

What are the company problems/opportunities?

What are the user problems/opportunities?

Note: projects may address only one of these problem types, that’s ok

Who are the internal customers? How concrete or speculative are these customers?

Why is this important? What is the expected impact?

Why are we proposing this at all, what happens if we do nothing?

What does success look like? What metrics will be tracked? What key result/ KPI are we hypothesizing this will drive?

What problems or opportunities are not being addressed? (What is out of scope?)

Can this be split into separate pieces to address risk and/or deliver value sooner? If so how?

What cross-team dependencies is this project likely to have? Who are the other EPD or non-EPD teams (Compliance, Marketing, etc.) who need to be involved?

Before the review schedule with Anaid’s EA the appropriate time slot at least 3 days in advance. Send the pre-read (Phase X doc) 

at least 12 hours before to the attendees.

The following people should be part of the review:

Product Leader - Will be the Approver and ensure alignment with goals and priorities

Eng Leader - Will determine if we should staff from the eng perspective

EM of your team (or delegate) - Will determine when we can staff from the eng perspective and who should work on this.

Design Leader- Will determine if we should staff from the design perspective

Business Owner (Demand/ Supply / Marketplace/ BizOps head or delegate) — Should provide input on whether the business problems and success metrics are represented

TL, if already assigned — Will provide technical input if needed

PMs/EMs/TL for potentially affected EPDM team - please include them only if there is a clear dependency, otherwise they can be informed through EPDM Meeting Notes

Project agreed with no further Phase reviews needed (depending on the project it may make sense to have informal progress reviews or asynchronous progress updates)

Project requires a 2nd Phase 0 review to address the raised questions ← 

this could happen if there are major pieces/data/support/perspectives missing in the Phase 0

No further work at the moment - project put on hold ←

this could happen if it turns out not to be a high enough priority, there are insufficient resources, or it is not the right direction

Send list of decisions, next steps, and recording to [team meeting notes email list]

Phase 1 - What’s the best way to solve this problem / realize the opportunity?

Product Development Process at Nuvocargo

Product Development Process and Reviews at Nuvocargo

Summary

Objectives

Sign up to see more