When I joined Fave as a new product manager, I was eager to understand how the team's product processes work. I met with each product manager and asked them how they do it. What surprised me initially was that they all followed different processes.

This came from the fact that different teams and their product verticals were in different stages of maturity in the product development lifecycle. While some teams were working on established products that were deeply embedded in the processes of the rest of the company, others were still very young.

As Fave grew, so did our product teams and we realized our product development processes had to evolve to allow each squad to develop products effectively side by side, without disrupting the work of others.

The product development process can be generalised as following these 6 steps:

Discovery: For every initiative, the product manager and the product designer is to define the problem space so that he or she can, together with the team, come up with the ideal solution for the next product, or feature, to deliver the most value to the user. This can be done through various discovery methodologies.

Design: Once the solution has been defined, the product design team comes up with a design prototype. The prototype aims to showcase what the final product will look like, designed to look and feel as real as possible. This is also used to validate the product idea with real users to get early feedback before you invest time and effort into building the product.

Development: Based on the design prototype, the engineering team plans the development approach and implements the product. This can take sometimes just a few weeks, or months.

Testing: Whenever some part of the product is ready for testing, the QA team, makes sure that the product is bug free and doesn't introduce bugs in other parts of our platforms.

Launching: Once the product is ready to be launched, PM collaborates with the marketing team to bring it to market.

Measure: Once launched, the PM tracks the product's success metrics and based on that decides what will be its next iteration.

Please note that this is a simplified process and a lot more work goes into each steps. As Fave started working on more complex products, such as FavePay Later, or CardLink, we have large dependency on our compliance, finance, and operations team. Thus, during later stages of discovery, we have a feasibility check where we make sure all regulatory and compliance concerns are addressed, before moving forward.

Discovery & Design: Two peas in a pod.

In Fave, the product team consists of product managers (PMs) and product designers (PDs). While each have their own distinct role and responsibilities, there is also some overlap.

Product Managers: PMs are responsible for collaborating with the engineering team and translating the product's requirements into product requirement documents and user stories.

Product Designers: PDs are responsible for designing the ideal user experience and making decisions on what feature sets are required to ensure the user can achieve their goal.

People are traditionally more experienced working with UX designers.

UX Designer

• Design consistency
• Usability
• Personas
• Information Architecture & Workflows
• Content / Copy
• Interaction Design

Product Designer

Everything on the left, plus...

• Business impact
• Product strategy

This means there is a clear overlap between the Product Designer and the PM (just like there is some overlap between the Engineering Lead and the PM when it comes to working with engineers). This empowers product designers to come up with product solutions that fit better into the company vision and allow them to shape the problem space.

So how do we draw the line? That is probably where new PMs coming into Fave struggle, there is not necessarily a line. The line gets defined on a per-initiative basis.

Overall prioritization is done by the PM - they decide what will be the next initiative to present to engineers. Before something gets presented to engineers, however, any initiative runs through the Discovery and Design space. The overlap is in the area of discovery. Both, PM, as well as PD, are empowered to tackle and explore problem statements and come up with the proposed solutions. This involves collaborating with stakeholders, running design sprints, talking to customers, and analysing data to come up with the right problem statement and the product requirements to solve the given problem.

Defining the solution: Planting a tree.

When humans think of problems, their mind is wired to jump to the first solution that comes to their mind - and we tend to think that this is the only, and best solutions. Any product manager that runs multiple product iterations will get humbled over time and realize that their intuition and first solution is often wrong.

That's why at Fave, whenever we explore a problem statement or chase a metric, we tend to break it down into what is called a Opportunity Solution Tree.

An Opportunity Solution Tree (OST) (from ‣) is a simple way of visually representing the paths you might take to reach a desired outcome.

The idea behind this is that when you break down your product strategy (the outcome you are driving at a given point) you would want to break it down with enough latitude (number of layers).

Having more latitude basically helps your brain to structure the several opportunities that you have, going from large, to medium sized to bite sized. The layers that we usually use are:

1. Themes or Initiatives (i.e. FavePay Later, Lucid, Fokuz, Project Evo)
2. PRDs or Features (i.e. Phase 1, Search, The Hub)
3. Tickets or User Stories

The focus on the Opportunity within the OST also forces us to think about what we're trying to achieve and the problems we want to solve. Once we nailed down which opportunity to tackle first, is when we work on the solution. This reduces waste. For each theme, there are multiple ways to implement them, and for each features there are different user stories that we can prioritize first.

Validation: Reducing waste

At Fave we like to "think big, but start small". This means when we create our solutions in the form of the design prototype, we have the ideal state in mind. Before we build out the full thing, however, we would ask ourselves, how we can test our assumptions.

There are several ways to test our assumptions, which all have a certain amount of effort associated with them. The easiest way for you to validate your assumptions is to talk to customers. However, whatever customers tell you, you always have to take with a grain of salt. On the other hand, you would get the most learning if you went ahead and built the full product: you will know for certain if it worked, or not, but the effort required is the largest. And if it goes wrong, also the amount of waste.

At Fave, we always ask ourselves what level of confidence we have about an initiative depending on what we know. If we have low confidence, we might lead with customer interviews. In any case, we will always learn something that informs how we envision the final product. MVPs help us get a working product in the hands of our customers as quickly as possible, maximizing our "bang for the buck".

MVPs are not an excuse to launch what are so called HAP (half-assed products). When we say viable, we mean products that have enough features and delight for our users so that they actually have a chance to be adopted. We also call them Minimum Lovable Products (MLPs).

Once a MVP is launched, it would be haphazard to just move onto the next thing. We need to give our products enough time and resources to flourish to iterate and flourish. Otherwise, we would just be building up product debt over a bunch of features or products that nobody is using.

Each product has a product metric and a minimum success criteria. We only allow ourselves to move onto the next initiative, once the minimum success criteria has been achieved. Otherwise, we iterate.

Measuring success: The North Star Metric.

Usually the most prominent metrics in a business are the so-called business metrics.

It's easy to track business metrics. They're usually lagging indicators, like $ GMV, # transactions, # merchants onboarded.

However, they are not good product metrics. They muddle the impact that you as PM and your product trio can have and depend on Marketing, BD, Sales, or Ops teams.

The way we discover a product metric is by finding a success metric that can directly be tied to the business impact this product initiative is supposed to bring. We can most easily do this by following the North Star Framework. Our North Star is Digital Transactions. Digital Transactions directly lead to GMV. The North Star is a function of Breadth, Depth, and Frequency

• Breadth: How many more users are you getting to use the feature?CTR, increase in number of users using the feature, ...
• Depth: How can you increase how far users get into using the feature?Funnel conversion rates, order volume, ...
• Frequency: How can you increase the frequency of usage of this feature?Retention, transactions / month, ...
• Efficiency: How can you increase the freqSpeed of transaction, percentage of successful submissions, ...

Good product metrics are rations, instead of absolute numbers, since they tell you how effective you are at converting users from one step to the next.

This does not mean that we are not tracking business metrics as a product team. They're still important. For one, it's much easier to prioritize between initiatives using business metrics. Feature success metrics are usually more difficult to compare with each other. They're also much better at highlighting the measurable impact on the bottom line that our team has done, which helps in motivating our engineers and inspires them to do more.

Empowered Engineering Teams: Three peas in a pod

Well-known product guru Marty Cagan has built his personal brand around Product Teams vs Feature Teams. What he means by that is that product squads (PM + Engineers) build better products if they are bought into the company, and product vision and understand it fully.

“The little secret in product is that engineers are typically the best single source of innovation, yet they are not even invited to the party in this process.”

— Marty Cagan, Product vs. Feature Teams

The most crucial information that an engineer will want to know is: “Why does my work matter?”. If your Engineering Lead is able to spearhead this, it will carry much more weight.

Engineers who know why their work matters deliver better work more consistently and faster

In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility.  The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us.

We achieve this by pairing each product manager with an experienced engineering lead. The PM and engineering lead share their OKRs. This builds a behavior where the engineering lead routinely sits at the table together with PM & PD when the product roadmap gets defined.

Furthermore, the product manager embeds regular business & release reviews into our Scrum process. During sprint plannings we usually reserve a segment in the beginning where we share about our most recent product launches, or any important business updates. Our engineers learn about our customers, who they are, why they need to use a certain product, and finally deeply understand the value proposition of our product. This allows them to make decisions independently on how the product is built and can easily suggest alternatives on how to build the product and deliver value more effectively.

Our product development lifecycle is evolving constantly and reflects product principles originally established by various product leaders and authors. We simply picked and chose what works for us. The authors have been linked in the article, so feel free to read more about the different topics!

If you resonate with how we build products and want to work at a start-up where we put our users first and constantly innovate, make sure to drop by on our careers page!

‍

‍