Project Overview

Role(s): Product Manager, Cloud Engineer, Frontend Developer

Timeline: 6 months

Project Type: Two consumer-facing mobile apps and a web application

Team:

• Tassy Omah (UI/UX Designer)
• Godwin Asuquo (Flutter Developer)

---

Project Introduction

After exploring creative passions for 4 years through photography, design, coding, branding, and marketing, I stumbled into product management. When Chidi reached out looking for a team to build an app, I saw the potential and took on the role of Product Manager. This is the story of how we built Tradr.

The Problem

Many people are either too busy, physically challenged, or simply don't want to deal with the stress of commuting to local markets. These individuals prefer shopping from local markets because of the variety, competitive rates, and quantity of products available, but they have no convenient way to access them. They desire to have their shopping needs fulfilled from the comfort of their homes.

Initial Expectations: Being completely new to the startup space, Chidi needed someone who could guide him through the entire process of building an application, working with and hiring a team, and ensuring we were building the right product to solve the right problem. I suggested we start with a strategy session.

---

Process

Project Strategy

After running a consulting agency during my 4 years of exploration, I developed the skill of facilitating strategy sessions. This is the most important step in figuring out what we need to work on and ensuring everyone is aligned.

The Problem Statement

A lot of people are either too busy, physically challenged, or simply unwilling to endure the stress of going to local markets themselves. These individuals prefer to shop from local markets because of the variety, rates, and quantity of products available there. They desire to have their shopping needs made available from the comfort of their homes.

Available Market

People who want to quickly shop for items at local markets at good rates but don't have the time or physical strength to go to the market. These individuals are usually busy and need help shopping for items they need in their homes.

Target Users

User 1 - The Reseller

People who buy things in bulk hoping to resell (The Wholesaler)

Needs/Goals:

• Buy products in wholesale quantity
• Build trust and relationships with sellers

Pain Points:

• Don't want to deal with the stress of commuting to market
• Limited varieties available
• Spending more than market rates (price point)
• Not being able to get detailed information about products from sellers

How We Help:

• Guarantee trust
• Confirmation of items purchased
• Handle the delivery process

User 2 - Price Comparer

Wants to check and compare prices of items in local markets but doesn't have the time to go

Needs/Goals:

• Compare prices of items in local markets without physically going

Pain Points:

• Spending more than market rates
• Needs more information on items and prices

How We Help:

• Provide a quick and easy way to connect with a shopper and ask about prices

User 3 - The Everyday Buyer

Individuals who just want to buy everyday items like foodstuff, clothes, toiletries, jewelry, etc.

Needs/Goals:

• Buy items from local markets
• Get items delivered

Pain Points:

• Having to leave the house to go to the market
• Not having someone to help them run market errands

How We Help:

• Guarantee trust
• Confirmation of items purchased
• Handle the delivery process

The Idea

A platform where people can easily get the experience of an offline market transaction where buyers and sellers can interface and engage in negotiations. Link users with shoppers who help them buy the things they want to buy. Being able to shop from a major market and experience all the benefits of being there without actually having to go there.

Key Assumptions

• People want to purchase things at major markets because they want to get a better deal
• Distance is an issue, so they settle for more convenient options (Jumia or shops around their neighborhood)
• People would want to have a contact in the market and would love to do transactions with them

Critical Questions

• Why would people want to come back to the platform after being linked with a seller or shopper?
• Would the shop owner give the shopper goods before payment?
• If a user is allowed to pay on delivery, does this mean the shopper has to shop with their own money?

The Solution

The solution could go in many directions as each user persona has slightly different needs. The goal was to pick a need to focus on that would be the easiest to manage in the beginning.

Identified Needs:

1. Connect with sellers in markets and buy products wholesale with the aim of reselling them
2. Being able to compare prices of items in local markets from the comfort of their home
3. Being able to purchase everyday items from local markets from the comfort of their homes
4. Get their purchased items safely delivered to them

For this version of the product, we targeted the "Everyday Buyer" — people who go to the market at least once a week or bi-weekly because they're more likely to use the application more than once.

Final Solution

A platform that connects individuals with shoppers who help them make purchases in local markets without having to be physically present and ensures the safest delivery of their purchased items to them.

What Does Success Look Like?

Success is achieved when the everyday buyer decides to come back to use the application for all their market runs because they trust the quality of the goods and the ease of the service. Success looks like when you go to the markets and at least half of the people there are shoppers getting things for buyers who are at the comfort of their homes. Success looks like people stopping buying goods from expensive supermarkets and choosing instead to shop on Tradr.

---

The MVP

Since the solution is a platform, we had to break down exactly who this platform connects and what role they all play:

User Categories:

• The Everyday Buyer
• The Local Shopper
• Logistics/Delivery Person

The Goal:

Create a simple system that connects an individual with a local shopper who can make purchases on their behalf, after which the items are handed over to the delivery person and sent out for delivery.

This helps us validate and figure out 3 key business questions:

1. Do people want to purchase things at major markets because they want to get a better deal?
2. Would people want to have a contact in the market and would love to do transactions with them?
3. How might we help deliver goods people buy from local markets at scale?

Initial Flow (Alpha):

a. Create shopping list → Connect with shopper → Items are purchased → Payments are made → Items sent out for delivery

b. Create shopping list → Connect with shopper → Items are purchased → Items sent out for delivery → Payments are made

Users are linked to shoppers who help them complete their offline orders. The user is matched with a shopper based on the items they want to purchase and the shopper's expertise (for example, some shoppers are better with clothes, while others are good with foodstuff).

---

User Journey Map/Flow Session

The next step after the strategy was the user journey map session. This was a session I facilitated with the core team and the designer present. We went over what we imagined the flow to be like using Miro. This part is very important so everyone feels they have input into the solution being created, even though not all their suggestions make it to the final user flow.

This part was also a key part of onboarding the designer to the project easily as she was part of the user journey mapping process. The user flow also helped identify key questions around how the app might work.

---

Design

The design started right after the user journey map session, and I worked closely with Tassy to create the design for the apps. The flow started from a simple flow map in Miro that helped us get an understanding of how the app might work and also helped us ask key questions.

After we were done with the map, Tassy created a low-fidelity UI for the app based on the user flow. The goal was to shed more light on what the design could look like so we could both be on the same page before even opening a design tool. This could have also been done on paper and pen, but Miro has decent low-fidelity prototyping tools.

The goal for the low-fidelity prototype was to go over each page and identify what features each page would need. This was a very important part of the design-development handoff because we already started thinking about the features we might need at a very early point in the design process.

Login/Sign Up

The onboarding is followed by a create account and sign-in flow to access the platform.

Home Page

The aim was to simplify the content on the home page and create actionable experiences that keep users engaged with the app. The major goal of the home page is for users to be able to create their shopping lists and find available markets they can shop from.

The fundamental goal of the buyer's app is to find shoppers to help them shop for items they need without having to leave their home. In the process of shopping for items, they're prompted to create a shopping list, and afterwards they engage in a shopping conversation with the shopper they've been connected to.

During the shopping session or conversation, they receive images and details of specific items in their shopping list individually, and they're prompted to either confirm or decline it. They accept if the item happens to be exactly what they're looking for and decline if it's not. Only confirmed items are added to the shopping basket.

Create a Shopping List Flow

Here buyers are prompted to write down details of items they need to shop for.

Shopping Conversation Flow

Here buyers engage in a shopping conversation with their shopper immediately after their shopping request is accepted.

Checkout Summary

Once a shopping session ends, the confirmed items are listed in the shopping basket. This is followed by a progressive flow that prompts the buyer to either select an already saved address or add a new address and a phone number down to the checkout summary. This allows a buyer to see all info related to the shopping and a call-to-action button to pay for all items that have been confirmed. The items are bought and processed for delivery once payment is made.

Order Details

This allows a buyer to view all the details of a shopping order and be able to track, view list, or re-order. Also allows the buyer to request support or reach out to management.

Flow for Shoppers App

The goal of the shopper's app is to be able to shop items for buyers who need their services. The shopper has to go live in a specific market so they receive shopping requests only in the market they're available to shop in. When they accept a request, they engage in a shopping conversation with the buyer.

The shoppers are meant to be in the market such that when they accept a shopping request, they start visiting local shops in that market to find those items listed in the shopping list.

Shopping Conversation

Before the shopping session, after the shopper has accepted a shopping request, they have to click on the start shopping button so the shopping duration timer starts running.

How the shopping works: During the shopping session/conversation, they capture images and provide details of items in the shopping list individually and forward to the buyer for confirmation. Either of them can choose to end the conversation when the shopping is completed.

Note: The flow is longer than this with each page showing every single detail and interaction. I picked only a few pages to visually represent the idea in my case study. I'm certain you would love it more when you get to use the actual product!

Shopping History

The shopping history for the shopper shows a list of the details of the shopping the shopper has handled over time.

Order Details

Shows the full details of a particular shopping order completed.

Shopper Earnings

For every shopping request a shopper accepts and completes, their earnings are shown in the order details and in their wallet. The amount they make depends wholly on how many shopping requests they're able to complete daily.

---

Development

Once the design was about 85% complete, I hired a Flutter developer to help us build the application. For the MVP, I picked a tech stack of Flutter and Firebase for the mobile app and was looking for a Flutter dev that also had Firebase experience. That's how Godwin joined the team.

Data Architecture

The developer onboarding was slightly different from the designer's as it started with a technical call that broke the app down into data structures. We had to figure out how we would be storing the data on Firebase, breaking down the document and collection structure for all the data.

Since I have extensive experience with Firebase, that call was fairly easy. I just had to make certain decisions considering the tradeoffs and limitations of the tool, which I am fully aware of.

We went over things like variable names, documents and collection structure, and how data are linked since we are using a NoSQL database (Cloud Firestore).

Building the Mobile App

Once we were clear on the data, it was easy for Godwin to begin working on the code and building the app screens. At that point, we had not implemented any functions; the goal was just to get him working on all the screens, then we would come back and link the functionality later.

Connecting to the Backend (Firebase)

While he was building the Flutter mobile app UI, I was working on the Cloud Functions backend. I moved all the app's functionality to the backend for better security and more predictable calls to the database. I didn't intend to build the backend but had to take it up because of speed of execution, security, and also to ensure there were very minimal to no mistakes coming from the backend.

As with the design process, I had to go over every variable name, function names, and how they are implemented (what parameters to send to the functions). I also had to come up with ways I think certain functionalities might be implemented. Basically, a lot of building, unblocking, and giving clear directions where needed.

The most interesting function I built was the one that calculates the service fee for each transaction on the app. It takes a lot of parameters into consideration like duration of shopping, the number of items purchased, and also price of items. I had never worked on something like that, but it was very interesting.

Connecting to Mixpanel

This is the more fun part of being able to write code — I can fully control exactly what I want to track and send to Mixpanel. I've never implemented Mixpanel before as this is the first project that I've had to implement analytics on, but I've been able to add some basic analytics for the app and can track a basic conversion funnel. This is still an ongoing process, and I would add more events as we open up the app more. Data is the lifeblood of product management, and being able to see the data in a dashboard is very interesting to me.

Internal Testing / Design Updates

We ran a lot of internal testing while we were developing the app and figured out that some of the designs could be improved and updated. In some cases, designs were completely revamped, which was a headache for Tassy, but she came through for the team.

---

Launch Strategy

There is a saying that you launch when you get your first user to sign up. Knowing fully well the code was far from stable, we decided to go for a soft beta launch with real shoppers and buyers who would help us test the app and find any bugs or improvements we need to make before the main launch.

This strategy has been very helpful, and we have already discovered quite a handful of bugs and updates that we need to make. Also, this is my first app in the Google Play Store, and I was pleasantly surprised how easy it was to have an open beta using Google Play. Haven't tried the Apple Store just yet.

It's been some time and the bugs are still not fully smoothed out, so Chidi directed that we route the buyers to a WhatsApp chat so we can use that to take orders for now. (This could have been the MVP months ago!) Our in-app chat has a few bugs that need to be fixed before we slowly roll out the updates that allow users to do everything on the app.

---

Results and Impact

• 2 apps live on the Play Store (in open beta)
• 2 usability tests conducted with real shoppers in an actual market
• 300+ users signed up
• 48 active users
• ₦20 million in total sales

---

Learnings

This is my first major project as a product manager, so what did I learn?

Well, I'd like to start with the elephant in the room: the MVP could have just been a WhatsApp chat from day one. So why didn't we implement this? I think it's a mixture of a lot of things, but I feel it comes down to the balance between traction and product value.

I didn't feel there was much pressure or need for early traction as the model of using WhatsApp already exists. So the focus was more on product value and creating a system that can deliver that value in a controllable way so we can be aware that transactions are being done. As time progressed, the need for traction increased and slowly outweighed the intended product value.

I think there isn't a one-size-fits-all approach. In some cases, traction/validation is important, and in other cases, product value is important. I still fully believe we could have continued to launch with the in-app features as it's basically all done, just a few bugs here and there, which is perfectly normal for an MVP. In fact, users can use the app and help us fix the bugs even faster.

Key Takeaways:

1. I would love to experiment with the idea of having design and development happening simultaneously to avoid having to make the designer work twice as much
2. I learned how to work better with a team and how to give proper feedback without being angry or spiteful
3. I learned how to lead a remote team in many different locations around the world and how to coordinate all of them to achieve the goal of launching

---

Next Steps

We are currently still in open beta, and anyone in Nigeria can download the app right now. Once we fix the bugs, we would slowly test a few users using our in-app chats and other features and slowly roll out to all the users.

---

Want to Reach Out?

henry@thinksenpai.com