"Building Products at mPharma" with Blessing Mikairu
Blessing and I chat about how mPharma thinks about strategy, team setup, and software tooling.
Product Manager Profile
Name: Blessing Mikairu
Past Experiences: Product Manager at mPharma
You can find Blessing on LinkedIn.
Introduction
Douglas: How did you discover mPharma?
Blessing: I learnt about the job opportunity from a friend who shared the job description for a data analytics product manager at mPharma. Although I initially had doubts about my fit for the role, my friend mentioned that Mpharma had a significant presence in Ghana, which piqued my interest. I reached out to Dika Oha, who was at mPharma at the time, on LinkedIn and expressed my interest in the position, sharing my background. He encouraged me to apply and assured me he'd keep an eye out for my application.
I applied, and he interviewed me, but he had left the company by the time I joined mPharma. Nonetheless, I was impressed by the company's reputation, the calibre of its team, and the positive impact of its product. It felt like a wise career move for me at the time.
Douglas: What were you hired for or what was your first product or project?
Blessing: I was hired for the analytics PM role, but it turned out different from what I expected. Initially, I thought I'd be working on various data-driven products, but it was mostly analysis. My first project was to integrate data into Halton's operations after mPharma acquired them in Kenya. After that, I tackled another similar project, analyzing the return on investment for a campaign.
However, my defining moment came when I identified a gap: mPharma lacked a dedicated data product for retail pharmacies, a crucial part of our mission. I took it upon myself to address this, even though I lacked a full team. I quickly created a Metabase dashboard with essential pharmacy information, a task my team estimated would take weeks. Surprisingly, I completed it in just 24 hours. The positive response from key account managers and customers convinced me this was the right direction.
Two months later, I finally secured a dedicated product team, and we built the retail pharmacy product from scratch. That became my most significant contribution at mPharma.
Douglas: How would you describe the product culture at mPharma?
Blessing: It's generally more product-led, Product managers are responsible for determining the "what" and "why" aspects of our initiatives. Engineers are then engaged to address the "how" of these projects.
Recently, we've introduced a quarterly goals framework, which is divided into 60% for product-related objectives and 40% for engineering-related tasks. This allocation allows our engineering team to address technical debt or explore innovative ideas of their own. However, the primary driver remains the product team's objectives.
One unique aspect of mPharma is its heavy emphasis on operations. This leads to some teams outside of the product department also building their own products. For example, the functional excellence team within our supply chain division creates products to streamline logistics and supply chain operations. So, while there are exceptions, the overall direction remains predominantly product-driven.
Roadmap and Strategy
Douglas: How do you decide on what to build?
Blessing: In deciding what to build, several factors come into play. Firstly, we align our projects with the company's annual goals to make a meaningful impact. Secondly, as a Product Manager, my portfolio influences the direction of my projects. Additionally, stakeholder input, including operations and customer feedback, plays a crucial role. These insights help us create products that cater to specific needs. Lastly, we consider strategic bets and incorporate them into our roadmap.
The process involves regular roadmap updates and quarterly goal-setting sessions. The goal-setting sessions involve at least two sessions for non-product and engineering leaders. It’s the C-suite, various heads of departments, and other relevant people like key account managers.
During these sessions, I present my goals, provide background information, and gather feedback from various stakeholders, including my team, engineering leaders, other product managers, and product leadership, ultimately ensuring alignment with the company's vision.
Douglas: What's the role of the product team in making the overall company goals?
Blessing: The Chief Product Officer (CPO) has input into overall company goals, our role primarily revolves around specific product goals. For instance, we might have a goal to expand our presence to 2000 stores. As someone responsible for the facility owner's experience, I consider how I can contribute. It may not always be possible, but I can explore improving the experience for existing owners, possibly by creating a referral program.
Douglas: Can you walk me through a typical feature? And how does that work from inception to launch?
Blessing: The typical process for developing a feature can start from various sources such as customer feedback, strategic decisions, or product leadership directives. Regardless of its origin, the process usually involves discovery. This entails talking to customers and stakeholders to assess the feasibility and value of the idea. Sometimes, it requires crunching numbers to make a convincing case for pursuing the feature in the next quarter.
Once approved, the feature is added to the roadmap and quarterly goals. The process kicks off with a problem brief, which defines the issue, the current user experience, the desired improvements, anticipated impacts, limitations, and a typical user story. This brief is reviewed by relevant parties, including the VP of products and operational stakeholders.
Design collaboration begins as the brief is shared with a designer, marking the start of proper design work. This involves back-and-forth discussions, questions, and the creation of prototypes or initial designs. Testing with customers and stakeholders, along with design reviews involving the product and engineering teams, follows. Feedback is used to shape the product.
Before the design is finalized, the team provides input and feedback. Once design revisions are complete and approved, the project transitions to engineering. Engineering considers architecture, resource requirements, and technology stack before starting development, which may take weeks or months, depending on the project's scope.
During development, incremental testing and the creation of tracking dashboards occur. Product marketing is engaged to plan the launch, and stakeholder input is considered. The launch might target specific customer segments, countries, or facilities.
After the launch, continuous feedback collection and iteration begin, forming an integral part of the product development process.
Douglas: How do you decide what actually gets on the backlog or what gets into the roadmap?
Blessing: Deciding what goes into our roadmap starts with my initial discovery phase before involving others. For instance, I recently had an idea to revamp a section of the mPharma website into a lead magnet. To begin, I wanted to boost customer acquisition through this funnel.
First, I checked who had access to Google Analytics to examine website traffic. I reached out to my manager, who then contacted the CPO. After reviewing the data, I found some promising insights. I shared this with my manager, explaining my vision and comparing it with the current experience.
I also consulted with the sales team, who would be directly affected. This early feedback was valuable. However, my manager questioned the impact, prompting me to dive into number crunching. Although it's not on the roadmap yet, I'm actively working on it. If my calculations convince my manager, I'll discuss it with the heads of sales in various countries.
Assuming they approve, I'll create a comprehensive document outlining the plan. This document will undergo review by my manager, who plays a hands-on role in my work. If he gives the green light, it goes on the roadmap, likely for Q3.
Next, I'll develop a design brief, involving my designer, and subsequently bring in the engineers. This phase includes further discovery work, both led by me and in collaboration with the design team.
Douglas: How involved is the PM in the delivery phase?
Blessing: I collaborate closely with designers to determine solutions, while also gathering input from my engineering team to ensure feasibility. This process unfolds concurrently with customer discovery. Once the design phase is complete, we do a design review and gather feedback. My tech lead assists in breaking down the work, and I sometimes provide additional details and acceptance criteria. I might also create a PRD document if needed. After that, I expect the engineering lead to drive development, with my involvement focused on progress checks. When it reaches the 'Done' column, I work with stakeholders and customers to finalize the release. Occasionally, I'm hands-on in planning the launch. It's a dynamic process, with my involvement varying at different stages as needed.
Douglas: How did you set that quality bar?
Blessing: I believe maintaining a consistent standard of quality is crucial throughout the entire process. For example, let's consider the process of crunching numbers – there's a quality standard there. Similarly, before we dive into design and engage with customers, there's a lot of collaborative discussion with our designers. We discuss ideas, evaluate their thinking, and establish a quality standard for design and user experience, tailored to our specific customer base.
As we involve more team members, they contribute to setting their own quality benchmarks. It's not just one bar; it's a collective effort to ensure quality. This standard extends to the engineering phase as well, where we aim for functionality without unnecessary issues.
When it comes to launching a product, especially when testing hypotheses in a specific market, there's a predefined quality threshold that we aim to meet before going live. In essence, maintaining a high level of quality is an ongoing process. My advice is to constantly consider and prioritize quality at every stage of the process, collaboratively defining what works best for your customers.
Team Setup
Douglas: How is your team set up? Do you work with squads? How is it set up from the management level down? The product team especially.
Blessing: We have a structure that's a bit complex. We have a Chief Product Officer (CPO) and a VP of Products for our retail division. Under the VP of Products, we should have Group Product Managers (PMS), but currently, we're missing the Group PM role. We do have Senior Product Managers, and there are no specific Junior PMs, just regular PMs.
Additionally, we have some teams that are not strictly product-focused but fall under the product organization. These include Product Operations, which handles product support, the Data Center of Excellence led by a Head of Data, and Infosect, which also reports to the CPO. While these teams aren't traditional product teams, they operate within the product organization.
Douglas: How do you promote sort of coordination and collaboration within an Engineering, Product and Design team?
Blessing: We organize our teams at multiple levels: PM, Senior PM, and VP of Product, each with their own squads.
In each squad, we have a technical lead, who, depending on seniority, might go by titles like Engineering Manager or Group Head. These leads oversee a team of engineers, and I also work with a shared designer from another squad. Additionally, there's a PM role within the team. This structure is consistent across all product teams at mPharma.
As a PM, I ensure everything stays on track through regular check-ins. I have standing calls with my engineering lead and designer, where we discuss backlog, team dynamics, and project specifics. Occasionally, we have more casual conversations. I also keep in touch with my team members through messages.
To monitor progress, I utilize various tools like Jira boards and communicate with our QA team. Furthermore, mPharma has chapter leads for engineering areas like front-end, back-end, and QA. While these leads have IC roles, they also guide their respective chapters, setting goals to improve work quality, which contributes to our quarterly engineering objectives.
Product Process
Douglas: Can you walk me through your product processes and rituals at mPharma?
Blessing: Sure, at mPharma, we primarily follow an agile approach. We have regular Scrum events like stand-ups, backlog sprints, planning, and retrospectives. Additionally, we conduct a retro specifically for goal setting every third month of the quarter. I write down goals, advocate for them, and once they're accepted, we work on them. Another crucial process is "release readiness."
Douglas: Could you explain what "release readiness" entails?
Blessing: Certainly, release readiness is a formal process where we involve stakeholders to gather feedback on our product thinking. The release readiness process isn’t for engineers. It is a distinct formal process championed by product marketing where the goal is to talk to operational stakeholders about 3 times before the launch of a big initiative. It is done once a month and the PMs decide what is worth presenting.
While PMs often informally handle this themselves, release readiness brings in heads from various departments to review our work. Their feedback is integrated into the product. Besides that, we conduct demos at the end of each sprint, where product and engineering teams showcase their work. We also have company-wide demos hosted by the product managers, showcasing recently released or upcoming products.
You might present an idea you are pursuing, some early design iterations, work currently in development, or a product that is ready for launch. Devs and designers can sit in these meetings but they are not necessarily the target audience.
Also, a PM is always involved in planning the launch. You might get help from Product Marketing but it is primarily your launch
Tools
Douglas: Let's talk about the tools you use at mPharma. What's your roadmapping tool?
Blessing: We use a format created by a group PM and shared in a dedicated doc for each product team.
Douglas: Great! How about documentation?
Blessing: We mainly use Confluence and Google Docs. Regarding documentation templates, it varies by project. We use NCT for goals, and there's a format for problem briefs.
Douglas: And for project management?
Blessing: Jira.
Douglas: How about analytics?
Blessing: We use Metabase and Mixpanel, with some teams using Google Analytics occasionally.
Douglas: What about user research and design?
Blessing: For design, we use Figma. User research varies; we consider Intercom a significant source. We use surveys with tools like Typeform and rely on conversations and discovery docs, mostly in Google Docs.
Others
Douglas: How do you stay up to date with the latest product trends and techniques?
Blessing: I primarily stay updated through newsletters.
Elena's Growth Scoop by Elena Verna
Data Analysis Journal by Olga Berezovsky
Douglas: How can companies support PMs in their growth and development
Blessing: I've been fortunate in my PM roles. My managers had solid product backgrounds, with established processes for personal and professional development. At my previous company, we held monthly one-on-one meetings with a document outlining my goals, both personal and professional. For instance, my interest in product growth was noted, leading to goals in that area. I also have weekly one-on-ones with my manager. These meetings involve sharing resources and specific tasks to improve needed skills.
We had a career framework in place, specifying roles and expectations. Honest conversations took place about skill gaps and ways to fill them, with continuous integration into my work. When I initially joined mPharma, I had some issues with stakeholder management, but we addressed this through open dialogue and integrated it into my work. By the end of the year, feedback indicated significant improvement.
To sum it up, effective support involves formal career development frameworks, aligning development goals with key metrics, and having committed managers and employees who actively nurture soft skills as part of career progression.
Shoutouts
Douglas: Can you share the names of two individuals you've worked with or are currently working with who have had a significant impact on your career?
Blessing: First, there's Kwame Boler. He was the founder of the startup where I transitioned to the role of APM. Kwame recognized my interest in data and intentionally placed me in situations where I could develop those skills. The startup environment forced me to learn and adapt quickly, which really honed my data skills and taught me how to be efficient.
The second person is my former manager, Gavin Oxman. I've been working under Gavin for about a year and a half now, and I attribute much of my progress at mPharma to his guidance. Gavin is incredibly hands-on; he doesn't just accept completed work at face value. Instead, he provides detailed feedback and asks probing questions, which shows his genuine interest in my growth and the quality of my work.
Thanks again to Blessing Mikairu for taking the time to share her experience in building products, org design and product management. Connect with her on LinkedIn.
If you want to see more articles like this, drop a like, share and comment.