How to scale a digital product to Millions of Customers.
In the past few years, I have worked on teams that has built and shipped almost a dozen digital services used by millions of subscribers. I will share some insights on how to scale digital products. Stay with me .
To start with, I think we as product managers, have impostor syndrome and i think we should be really proud of what we do.
I will share with you how to make failures purposeful and how we can grow iteratively. Let’s go straight into it.
I have found that customers can make or mar a product and its fascinating how if you constantly serve them and tell fantastic stories about your product, you will find extremely loyal customers in terms of revenue, daily active users, monthly active users and constantly dropping churn rates. I have worked across teams from engineering, sales, marketing across the telecoms, retail and imaging verticals, where the business focused on high quality products at the best prices.
Most times, companies are planning, developing, iterating, agile but not transformative. I remember when the engineering team would say Salem, add a product owner to your team to know what we are doing. Sometimes, I have had comments where they say “your product owners are not thinking like business people”. I know you must have felt this struggle at some time too.
A big problem I have seen is that a lot of products are not customer centric and become too average. But a bigger problem is that we jump into solutions so fast. We love solution(ing) and then we find ourselves in the point of no return. We have n+1 number of solutions and we try to show that our solution is the best, entering a vicious cycle.
I have a question for you… Who are we actually solving problems for? When are we done solving? Or is it endless? Does the actual solution solve the original problem? If you are not answering these questions already, you should be. If possible, at every sprint cycle. Because this determines how you are working, the direction in which your business is going.
Now to research (I promise this won’t be boring ) — — — foundational and directional research, is important to any kind of product strategy. This is based on my experience and you won’t find it elsewhere.
Foundational — You walk into something, no idea about customers or their problems or how they are reacting, you don’t have data, no matrix, workflows all over the place. This happened 4 months ago when I saw that we are working with 80 tools. None stitched together and customers stitching them together themselves. Yes , 80!. I could not understand how they were going to work through this. This is the point I locked myself in the room, interviewed as many people as possible, came out with customer journey maps, future state, current state, personas, empathy maps, and a really good understanding of the problems to solve for. Great list of problems.
Directional — This is usually a short stint done very often, infused within our sprint cycle, and empowers the team to ensure they have a really great story to tell. If you ever think product strategy is living up there and not something that product managers’ own, you are wrong. Every PM owns the strategy. Please ensure that you can tell your story real well. Your team will be empowered when they know, you know what you are doing.
I have a strategy called Fuel — Framing, understanding, experimenting and listening. You should try it too in your strategy. My colleague said , salem, we know all the problems out there, why can’t we go ahead and solve them and not go into research? Sounds familiar right?
I asked him to give me an hour with his team of 10. We split them into two teams, different rooms. Asked him what he has for breakfast — Chris makes a toast before leaving home. Gave the team a mission — Make a breakfast toast for Chris. They had 20 minutes to ask him questions. Team 1 presented an amazing fast toaster that could toast bread in a millisecond. Team 2 presented an amazing app that could deliver toast and sandwiches to Chris’s desk in the morning. Guess who won. Why? Team 2 did. They asked deeper questions. They got to the bottom of what he was looking for. Chris wanted something that could be fast, not just toast.
Framing — This is when you differentiate between an iterations and an innovation. You must be able to frame your problems. Its internally done where there are deep-dives, debates between the products team, strategy team, UX team and the engineering team. I call them the 4 in the box. Blur the lines — everyone is SAME in these meetings. Problems are solved linearly. Never forget your 5W’s as well.
You will find a set of customers that you’ll need to solve for. Power users, specific users. You will need the matrix to measure then. This is draining, especially when you will need analytics.
Quick hack — start writing your press releases about how you solved the problem, the friction you have eliminated, how your product is differentiated, boom, you land on the matrix you’ve been looking for. At this phase, you can actually start working on something. I advise, if you are not sure, hold off on solutioning before diving in.
Understanding — Have power users. Pick your most loudest, unhappy, complicated customers and they will help you innovate the most. As a product user, have a good set of people in this space.
Sketch different options, co-create as much as possible. Have multiple versions of a scrappy prototype. Have a list of assumptions as you work through it. It has helped me validate in my next phase of workflow. Always come up with the most radical ideas that you feel might not work. They have ended up working for me. Push your team beyond boundaries. My best team is my UX team, though some UX teams go into analysis paralysis , but you can always guide them.
Experimenting — Here, we focus on pricing, feedback, testing and value proposition.
Importantly, always be realistic about solutions. Don’t be coerced to ship solutions. Never be afraid to scrap a solution. Never look for perfection, it’s the enemy to getting anything done.
Listening — Listen (purposefully) often — So you don’t develop a useless product — Synthesize your feedback (story) from framing, understanding, experimenting. I typically bucket feedback from current and future. Lately, I have never been interested in backlogs longer than 6 weeks old. I know teams that get measured on the depth of backlog, that’s wrong. Why should the depth of backlog matter?
Now, carve out your MVP, you have your next research list, have a list of NEVER SOLVE PROBLEM (Even twitter has one, the edit feature).
Feel Free to share with your fellow product managers and lets improve this collaborative learning habit. I am always available for chats on anything products growth and management.
