I wanted my first blog post to be a classic – like one of those “Things I Wish I Knew Before I Became a Product Manager”. Always popular, those ones. A crowd pleaser.
Problem is, I have about 1 Million things, AT LEAST, that I wish I knew before I became a Product Manager, and I’d very much like to publish something before I’m 60. So let’s start with something different. Let’s start with a story of failure – because this blog is for sharing learnings, and not just glories.
Let me start from the very beginning.
I heard it’s a very good place to start.
I work in a central capacity. And I’m part of a team that builds a Messaging product that has been integrated in (as of writing) 17 marketplaces spread across the globe. That means 17 different marketplaces in different time zones, speaking different languages, having diverse verticals, with different maturity states, prioritizing different business goals.
When I joined the team, I let out a low whistle and asked myself, “What have you gotten yourself into this time?!”
It was amazing. And I thought I was up to the challenge. I was going to be a Product Manager Superstar who would help build a world-class communication tool that would be the silver bullet to our marketplaces’ success. Let me get started on our roadmap!
I blame the rush from just having moved from Manila to Barcelona for the unprecedented enthusiasm and blind ambition.
Reality finally caught up to me, as soon as I was fully onboard the team and the project. Then the problems started to manifest themselves.
- The marketplaces we were supposed to integrate with didn’t want to integrate with us until we had Feature A, B, and C implemented in our product.
- The marketplaces that already have the product integrated were sending us a list of their feature requests faster than we could set our Slack status to “away”.
- Our roadmap, which was really just a Gantt chart of features to do (but let’s talk about roadmaps in another post), was growing at an alarming pace, but we were not getting anything done.
I could’ve said no to things, but I had no clear reason to say no. Our team of 6 (myself, a Technical Project Manager, and 4 engineers) was drowning in requests and non-negotiable pre-requisites. Needless to say, I was starting to feel that I was not doing my job well. And the team was feeling the effects of it too.
We were getting a ton of complaints from all angles. Some wanted to just fork the product. Some marketplaces didn’t want to work with us at all. It was a downer for sure. And so we started questioning the value of what we were building.
I also started wondering if I should pack my things.
But I was really starting to like living in Barcelona so I didn’t want to throw in the towel yet. Besides, it’s only been 3 months.
So we took a step (or 2) back.
We had problems. We knew that. What we needed was to find out what was causing our problems. So we took a deep breath, took a long hard look at ourselves, asked for feedback, and observed what other teams were doing:
1. We didn’t have data. At least we didn’t have our own. The most basic thing to have, I know. Except for the number of messages being sent, and not sent, we didn’t know exactly how our product was performing in the wild. We didn’t know how to get those numbers! It didn’t help that each marketplace that our product was being used in had their own different UI built on top of ours. So consistent data was unlikely either. It was starting to look like we had a different product across different countries, with us providing an API that the marketplaces can use.
2. Features, at the end of the day, were solutions. Solutions to problems and needs that the users have. We focused on the solutions when we should have been looking at the problems instead. A single problem can have many different possible solutions. For example, a problem can be that users are slow to respond to each other. This can be solved by adding push notifications to make sure that the users see their new messages on time. But this problem can also be solved by adding voice calls functionality, or have bots just take over the conversation for the users. The point is, we could have been building 5M solutions that will solve the same problem. The clincher? None of them could have been the right solution still because we didn’t really understand what we were building that feature for.
3. Our vision for the product was not clearly defined. We knew we were building a messaging product. But what was our purpose? What value were we providing to our users? Why do we even need to build a messaging product in the first place? All important questions that we haven’t asked ourselves.
Seasoned Product Managers reading this (if there are any) are probably shaking their heads right now going “Rookie mistake(s)!”. And they were. We knew that if we wanted to have any chance of “making a difference in people’s lives”, we had to make some difference in ours first. (And there goes the first cheesy line you’ll read in my blog! I promise you there will be more).
We started making some changes.
We had to. We needed to be better.
1. We first identified who our real users were. Are they the end users who were interacting with our product? Or are they the marketplaces who want to integrate our product into their sites? Either way, knowing who are users were would definitely define our approach to everything – how we define what success looks like, not the least of them. In the end, we decided the end users would be our primary well… users (not to be a Redundant Rita and all that). Because we knew who our real users were now, we could focus on their problems. We could focus our energies on understanding what jobs they needed to do and how they are accomplishing these jobs at the moment – and put them above all the rest.
2. We also changed the conversation with the marketplaces we work with. We stopped talking about new features to build (at least exclusively) and shifted the conversation to talking about the problems their users were having instead. After all, compared to us, they’re a lot closer to the end users so they know them better. And this was when we realized that the problems across the marketplaces are all fairly similar. Finding the similarity across all marketplaces helped us prioritize which problems needed to go first. We started involving the marketplaces more and more in our processes. From defining together what problems needed to be prioritized – to determining what success looks like should we solve these problems.
3. Even with the marketplaces more involved now, the responsibility to validate these problems, get the right data for them, and test solutions, still falls ultimately on our team. To do so, we needed more help. So our little team of 6 grew with the addition of a Product Analyst and a User Experience expert. With these new additions, we became more robust. And so we were able to set out and find ways to validate the existence (or the lack of it) of the problems we defined through qualitative and quantitative research. And for these validated problems, we were then able to determine the right direction for solving them.
And that’s how we got our groove back.
Prioritizing was so much easier when talking about problems. We found a common ground with the marketplaces, and the marketplaces found a common ground between themselves. With problems in the middle of our conversation, it was easier to give a reason for why something should be put at the top of our priority or not. And because there was a good reason, this went down the gullet a lot easier for everybody.
We started to have a better understanding of our users, their problems, their needs, and the things that they want to accomplish when it comes to using our product in the context of the marketplaces. And this understanding gave us the foundation to start defining where we want our product to go, our ambition – the value we wish to provide. Thus we were able to lay out what our vision is for the product and how we want to reach it. Even more reasons to say yes or no!
Fostering an environment of collaboration rather than a “we make a request and you build it” opened up a lot of new doors for us. We were no longer just a small team in Barcelona working on a Messaging product, we were a bigger team working on it just spread across the globe. We suddenly had more opportunities to test things. New insights were coming in from all corners of the globe, each presenting a different perspective that we probably wouldn’t have if we were working all alone.
Needless to say, things became better. Escalations to management about us definitely was not happening anymore, and we were starting to get some good feedback as a team. And more importantly, things were getting done. Our product was in production, and we were finally starting to see the rewards of our efforts. Users were actually happy to use our product (I read these feedback myself from the Appstore and Playstore). And soon after, we found ourselves right smack in the middle of the company strategy as a key enabler.
Ok, so it wasn’t happily ever after, of course. For one, we’re still working so we’re far from the end. And our team has grown in size since then. New challenges have come in, and new learnings have come out. But I have to leave some for later, otherwise, I would have run out of content and it’s only my first. 🙂
TLDR;
- We have a product that’s being integrated and used across 17 marketplaces across the globe
- Earlier on we didn’t have a good process for prioritization
- Our small team of 6 got overwhelmed with feature requests
- Thus we were not getting anything done at all
- Resulting in unsatisfied marketplaces who didn’t like working with us
- We decided to change our approach and our team set up too
- By identifying our users and defining our problems
- We worked to get more data through research and testing with the help of experts who joined our team
- And collaborated with the marketplaces on a much grander scale
- And now our lives are better with a stronger product whose value for our users and our marketplaces is set in stone
*****************
If you have any feedback, questions, or even violent reactions – please don’t hesitate to leave a comment or send me a message at hello@kaxuson.com
And in the future, if you’d like to receive updates from me, links to interesting articles and conferences about Product Management, and other interesting Technology reads to go with your morning coffee, then please sign up for my newsletter here. Don’t worry, I hate spam too. It’s also GDPR friendly (Mailchimp said so).