Exercising my Product muscle with 'Africa-Travel'
Product ·I’ve always enjoyed the idea of working with people to achieve a goal. Enabling talented allies to do the best they can. Be it a reliable team member in highschool volleyball, or a support champion in League of Legends - there’s something that gets me passionate about working with a group of fellow humans and working towards an objective. As a kid, I could see myself being a Project Manager of some sort, likely in supply chain. That kid is still there. As I’ve gone through studies, I’ve realized that the skills and work I really enjoy have to do with building products, and working with a team to do so. I luckily got the opportunity to do this at Credit Karma - where I did a 4 months internship as a PM for the services Recommendation team.
I’ll probably talk more about my experience and thoughts on Product Management in another post, but the gist of it is at the time of writing this post, I work as a Solutions Engineer at GitHub. This is an amazing role that has allowed me to develop a variety of additional skills - understanding the selling motions in B2B, developing business relationships, seeing how companies of various sizes (from startups to large Canadian banks) build software. And I’m able to do all this while staying technical, and working in a highly collaborative environment!
I’m super grateful to be in this position, but the product itch is still there. I find myself asking a lot of why’s in customer meetings, thinking about how to make experiences better. I find myself setting out roadmap and daily backlog goals, trying to optimize my team’s “product” of being a great account team for our customers. This is where my small project with “Africa-Travel” comes in.
I wanted to work on building something from scratch - solving a problem. I discovered a great excuse to do that when traveling to visit my family in Cote D’Ivoire in 2023. Although I have done the trip multiple times, my partner was traveling with me this time! She was going to Cote D’Ivoire, to Africa in general, for the first time. I had all my documents ready: residency permit, vaccination records, and the like. I even had citizenship of a country in the region, so I could use this if need be. Everything has been set up on my side as a frequent traveler to the nation. A kid of the diaspora (I don’t think I’d refer to myself as that but I guess technically I am) who knows his way around going to that part of the world. A part of the world not a lot of people are familiar with. That’s for another post.
For my partner though, we had to be a little more involved. For example, there are some mandatory and recommended vaccines for her to have taken. We also realized kind of late that there she needed an e-visa coming in with a Canadian passport. A lot of questions start arising. Does she need a visa for a 3 week stay? What documents are necessary for the visa? What about the vaccines, should we get the recommended ones? It’s ~$300 extra dollars, is that really necessary or are the travel agencies we’re seeing overprescribing? Are there any other expenses or preparation we should be aware of? I realized that there were a few things I took for granted when traveling back to countries in Africa, especially around the prep necessary. This could be more of a pain for someone exploring the continent for the first time, say someone from the diaspora who wanted to rediscover their roots, or just a general tourist. I discovered a problem to solve:
Today, young adults who are looking to travel to Africa don’t easily have all the personalized information they need to make a decision about where to travel to and prepare for that travel in a single location.
Now let’s get this out of the way - this is not a huge pain/problem like one being solved by the connection available by WhatsApp or the health services provided by the Government of Ontario. But it’s a great project - a pain I can help alleviate by making this information available to travelers. It’s perfect for my goal of “exercising the product muscle”. And so, I started with what my gut was telling me was a pain point and set out with a product framework in mind to help me address it: Understand, Identify, Execute. There’s a million frameworks out there, and my naive opinion says there’s no right/wrong one. But I really like this one I picked up in Peter Yang’s “Principles of Product Management”. I worked with Peter at Credit Karma, he is an amazing PM.
Understand
1. What is the problem?
With the idea there I set out to the first step - defining the problem in greater detail. You can find that here, where I used the idea of a typical customer journey today when preparing for a trip to Africa. I tried simulating what I would need to do to travel to another country on the continent I’ve never been to. I was asking myself a lot more questions than anticipated. Where should I even go? Is this visa info on this old government website up to date? I realized preparing for a trip could be broken down into 2 parts: the pre-decision, and the post-decision-pre-travel (I need a better wording for that). I get excited when I realize I might have tapped into a larger problem. This was getting a little bigger than just “preparing documents for travel to Africa”.
In any case, I had defined a problem, with the potential to uncover more. Now to sanity check myself.
2. Does this problem exist?
It is so crucial, as fast as possible when solving something, to determine if the thing you’re solving for even is a problem. Although I used to jump into solutioning immediately, this step comes a little more naturally today thankfully. I set out to talk to a couple of people about this problem - people who would be a target audience. My partner obviously, but also other young adults who I would consider diaspora kids. What are the biggest pain points they have about traveling back home? How much time/effort do they spend preparing for the trip? Typical questions I tried to keep as unbiased as possible. I asked about 5 people. Generally, I believe to validate a problem exists you have to ask at least 3 existing or potential customers. In an organization, you should probably talk to team members/experts as well before investing any time. Deadlines and workload already exist in the workplace!
The interviews were helpful - I got a sense that there was a pain, but that there were also other things to consider when traveling: chief among which is safety. I hadn’t considered it, but there may be a need to help people identify the perceived safety of certain countries as well. This is a larger and more difficult problem to solve, but definitely noted. As a whole though, what’s interesting is people didn’t really think of preparing for visa requirements or other as a huge pain point - it was only acknowledged as a pain after being brought up. I don’t think that invalidates the value of something to help with this though, as you sometimes don’t know a thing is a pain until there’s an easier way to do it. E.g. I didn’t internalize that I could avoid being sick every winter until I started eating healthier and getting some flu shots!
“Ok”, I told myself, “I’m not insane for this”. It was time to identify how to solve this problem
Identify
I do want to acknowledge here that I’ve skipped a critical step that would normally need to happen in an organization - expressing why it is critical the organization solves this problem. I felt there was no need to really define that here, as the idea was in its infancy. Expressing criticality is important to get resources, help, and most importantly alignment on any new product. As a company, there are near infinite problems to solve, and this element is key to product prioritization. It helps answer what solving this problem brings to the company. Usually that means aligning a product with an existing mission or metric to grow. Under normal circumstances I would go through this, but because this is a pet project and I’m doing some 0-1 here, the answer to “criticality” is “it’s important to me and will help people”. Simple!
1. Establishing a Mission, Vision, Strategy
When I say I had a product itch, this is specifically what I mean. I feel this phase in the product development loop allows me to indulge in the “dreamer” side of me. I get to think big, on how to take a concept and extend not only to a small problem but to a larger - potentially societal one. You can find what I have defined as MVS here, and if you decide to click on that you can see I extended it to more than just “preparing for a trip to Africa”. I envisioned a personal concierge, some Jarvis-type bot that could help you across the entire traveling lifecycle. From “where should I even go” to “ok, I’m here, how do I organize my itinerary”. Imagine an assistant that even helps you manage your finances for that trip!? It’s a fun thought experiment, but also a possible one.
For the strategy part - it’s not particularly unique. I went with the land-expand, it makes so much sense when doing a 0-1 or thinking of a business strategy, especially in a market niche that is sort of a “blue ocean”. I would love to be able to build out more unique strategies. In the real world, I would also vet this strategy thoroughly. There are definitely assumptions/things I have not dived into. Is the market of infrequent or new travelers to Africa viable to start with? I would need to do more research to find out if there is even a market.
2. Establishing a Roadmap
After dreaming big, for any product I’m responsible for, I would look to establish roadmaps for the product and then PRDs for individual features. I think when doing a 0-1, it makes little sense to have a concrete roadmap before even having something. Talk about creating friction by introducing processes unnecessarily. In this scenario, the idea is to get something off the ground quickly, and then from there building a roadmap. Get to the MVP stage, and go from there.
That being said, for the MVP it’s worth at least working out what’s in scope and what defines a successful MVP. Timelines aren’t needed, but requirements are. You can find my tackling of this in my PRD doc here, a format again stolen from Peter Yang’s great product framework.
I like the idea of summarizing in a PRD what exactly we’re looking to solve, and establish metrics alongside a hypothesis that defines how we’re looking to solve. User stories are a staple, which you can see under the requirements section, and for larger features an FAQ makes a ton of sense.
I see the PRD as equivalent to the GitHub pull request in terms of importance. Weird comparison at first glance, but both hold so much importance and are a crucial nexus for the processes in which they’re involved. The PRD would ideally be the source of truth for any work done, and would be a living breathing document as requirements are added/removed/etc.
You can see some of the low fidelity prototypes I’ve thrown together as part of this PRD here.
3. What about quarterly goals?
I missed a level between the overall Mission, Vision, and Strategy and the PRD: The Objectives and Key Results. I wanted to acknowledge that OKRs are a critical part of roadmapping and determine what the team executes on in the next months. Making OKRs for a 0-1 doesn’t really make sense (again, we’re trying to show value immediately), but once the MVP is done, I can imagine my first set of OKRs to look something like this.
Objectives are usually qualitative goals we’d want to achieve, and key results are the quantitative measures we will use to determine if we are achieving these goals.
Execute
With an identified plan, and even a semblance of a roadmap for the next quarter after the MVP, nothing stops me from getting started on the idea.
Execution is a very important aspect of this process, which I feel is worth reiterating. I can have a great strategy, but without proper support for all the teams that make the product happen, the product will fall flat.
You can see the code for this work on GitHub here, and the project board here. Again, there’s no need to overdo it for a 0-1, but I have broken it down into milestones -> Backend, Frontend, and MVP completion. Creating requirements/user stories and then implementing them myself has made me realize how little information I was initially putting in. It has given me appreciation of the Product Manager to Engineering Manager pairing, which is crucial to provide as much information as possible to Engineers. All that’s left is for the work to be complete.
In a business setting though, execution comes in 4 of phases: Kick Off, Betas, GA, Retro.
1. Kick Off
This is where my responsibility as product owner boils down to setting up execution for success: aligning the team on the understanding of what is to be built, by reviewing the PRD and setting up a motivating kick-off meeting. Before this, milestones would have ideally been roughly sketched out with the help of engineering.
Afte Kick Off and all along this execution process, the main thing I’m responsible for is alignment, and the main way I achieve this is via communication. Constant communication with the team (standups, etc.), with major stakeholders, and with other product teams.
The other thing I consider myself responsible for is putting out fires
2. Betas
At the different software companies I’ve worked out “beta” is another word for “dogfood” of “staff-ship”. I know at GitHub, depending on the importance of the feature it could go through alpha, private beta, and public beta before being released. These betas allow for fast feedback and pivoting if required. Being able to quickly gather feedback can help uncover things we might have missed, designers make user flow more intuitive, or in some cases even inform us that the product we are building does not solve the actual customer problem.
You’ll notice that in my PRD I list the objective as a hypothesis. Part of being an effective product team is quickly realizing when a hypothesis is wrong.
3. General Availability
As an SE, I know how important it is to effectively communicate a release to the appropriate audience, and I’m sure there are ways we can do this better even at GitHub. Whether it’s through the company blog or documentation, clearly communicating what is coming out to expecting customers can help avoid a poor experience.
Internally, I would look to work with a launch checklist to cover all bases. In several companies launch checklists are automated (have you written documentation, have you created a release issue on the public roadmap) but there are other elements to consider that could sometimes apply - like marketing or legal.
4. Retrospective
I’m a big fan of retros. It’s probably because I’m a big fan of feedback. Retros are a great excuse to celebrate my teammates and work together on identifying issues during execution.
Are there better ways to communicate as a team? Certain dependencies we should keep in mind? Customers we want to keep close? This is the opportunity to prepare ourselves for the next iteration of the Product Development Loop. Every retro makes us stronger.
This phase is also meant for post-launch monitoring. Is the feature improving the metrics we had set for ourselves earlier? Our job only finishes once we have delighted customers, not just after shipping the product.
Conclusion
I had a lot of fun working on this, and sharing it. A framework to the chaos of software development keeps me sane, and allows me to keep in mind what it takes to build things for people with people.
Although I skipped a lot of best practice product phases due to building something from scratch, I hope I showed at least some understanding. That being said I would love to learn about how other PMs think about building software, or get feedback if I missed anything. Please feel free to contact me.
I will update this blog with more details on the finished MVP once I have more time building it. Until then stay tuned 🙂