Companies that are too focused on themselves can easily fall into solutions they consider minimal and functional. However, the customer might have a different perspective. And with the right minimal solution, you are just one question away.

About Push Notifications
A successful corporation with a million users of its mobile app decided to add push notifications to the app. A simple change. At least from the user’s perspective. But not from the corporation’s point of view.

Behind the mobile app is a strong backend developed by a different vendor. The company has a robust ecosystem of solutions, so building the mobile app wasn’t too difficult.

The company was somewhat forced to implement push notifications into the app. Until now, they had an SMS solution, which was a paid service. The push notification would cause the company to lose part of its revenue and, moreover, require investment in developing the push notifications. But well, the customer is always right.

The initial design of the solution, however, shows that the backend was not built for an ideal push notification solution. The system could respond to requests, but it couldn’t alert users when necessary data changed. Additionally, the data processed in the mobile app varies in nature; some are aggregated, making it a significant intervention in the backend to track data changes and smartly notify users about them. And since the backend is managed by a third-party vendor, this would be costly and who knows when it would be done.

This presents a need for a Minimum Viable Product (MVP).

What Could the MVP Be?
Enabling push notifications requires configuration per client and per app installation. Until now, this wasn’t necessary, so the mobile app didn’t have any configuration. Here, an MVP solution presents itself.

Implementing the notification naturally requires identifying a change so that when a client taps the message, they can see the details of the change. But the backend did not provide such information for security reasons. After all, it didn’t want to publish the ID of the modified object. Again, an MVP solution is required. But what kind of solution…?

How would you solve this situation? Take a minute to think about it.

My Ideas
Minimum Viable Product
The solution that the client approved was minimal. From their point of view. Everyone in the company was satisfied with the proposed solution. It wasn’t the perfect solution, but it would be delivered faster than a perfect one. And, most importantly, it would be cheaper, especially since the company would lose revenue from SMS charges.

The MVP solution proposal:

  • The client enables push notifications via the web app, not the mobile app. The web app already has the customer profile configuration, so it can simply be added there. The mobile app doesn’t currently support this.
  • The backend sends a message about the change. Since the backend can’t deliver the ID of the modified data, it will be a general message like “There has been a change in your data.”
  • Tapping the message will open the mobile app.
  • Since the specific change is unknown, the initial dashboard will be displayed.
  • Functional, minimal, cheapest solution. MVP.

Wait! Minimum Viable Product?
Is this a viable solution?

When the Agile mentor asked this question, people started to feel uncomfortable:
“Why is he questioning this? We’ve been working on the design for so many weeks. We even made changes to the backend ahead of others. We’ve been fighting for this, we finally have a chance to do it and deliver it. Our competitors already have push notifications. We need them. Customers are complaining about not having them. Competitors handle it the same way. And now the Agile mentor questions it? Now? Let him try real work!”

But the Agile mentor isn’t questioning. He just asked a question. The team responded negatively. Why?

The responsibility process shows that the path to accountability starts with denial. Perhaps that’s why the team reacts so intensely to the question about the solution’s viability.

And perhaps it’s hard to admit the truth — that they feel the solution isn’t viable. That’s okay. It’s part of finding a responsible solution.

The solution might not be minimally viable for the client. And maybe that’s why you move into the second stage of the responsibility process: blaming. Even personally blaming the person whose role is to ask questions, change the way of working, and, most importantly, change the way of thinking. The person you hired specifically for this task.

Neither you nor the Agile mentor have the right answers. The customer and the user have the answers. And you’re just one phone call, email, or conversation away from those answers.

Ironically, the team members were also clients of their own company. The team members admitted that they wouldn’t use this solution. It didn’t make sense for them to go to the web version to set up push notifications. They hadn’t logged into the web app in almost a year. The mobile app sufficed. After all, logging in requires a user ID and special PIN. In the mobile app, they entered it long ago, but now they log in with biometrics. Guessing the PIN for push notifications? No way… What a waste of time.

And when the push notification arrives, will it just inform me of a change? I need to know exactly what has changed right away. I don’t have time to open the app.

And even if it does… Will the dashboard show up? The same one that appears when I open the mobile app?

Wait!!! So, we’re launching the app through push notifications? Seriously? For €X*10k? Really?

When It Breaks
And here we are. The moment it breaks. The moment you feel ashamed in front of yourself. You have the choice: either give in and continue with your ‘MVP’ solution, or meaningfully and responsibly fix it. Deliver not an MVP, but a Minimum Marketable Product.

Further details emerged later during planning. No one expected that when there are many push notifications about changes and many app launches at the same time, the displayed dashboard would trigger several heavy queries on the backend, which wasn’t built to handle such a peak in load. The backend started balancing the queries and slowed down the responses. Users saw a slow app startup after tapping the push notification. In the simulation, they even reported app crashes, which caused users to start manually restarting the app. Ironically, this led to even more load.

Have You Found Your Lesson?
What did you learn when you reflected on your approach, which you made somewhere in the middle of the article? Where were you wrong? What should have been different?

The decision about the minimal product lies with the user; the customer must confirm the product’s viability.

Just ask your clients. And listen to the people who ask the questions.

Today, everyone has the answers. The only question is if they are the right ones…

Or join the ranks of the best Product Owners in Slovakia who have completed our Product Ownership MasterMind programs: Product Strategy or Product Delivery.