App Product Strategy Looks Really Different Now
It’s kind of wild how much app product strategy has shifted in just the last few years.
On paper, the job still looks familiar. Ship features, run sprints, keep users happy, do not melt the team. But underneath, the shape of the work feels different than it did pre-2020. The questions are not just “What should we build next?” They are “What actually earns a spot in someone’s day?” and “What is worth maintaining, emotionally, cognitively, and operationally, over time?”
I’ve been deep in consulting, mobile app building, and AI-heavy product work through this whole shift, and I’ve felt it happening in slow motion. This is my note to self on what has really changed.
The old game was volume
Not that long ago, a lot of app strategy quietly boiled down to build more, announce more, hope usage catches up.
It was not wrong. It was just the default move when attention felt cheaper and when the market rewarded breadth. We optimized for the feature story. More menus, more toggles, more things to screenshot for a sales deck or a pricing page. If you could say “We do X, Y, and Z,” it felt like progress.
But the uncomfortable truth showed up after launch, again and again. A feature would ship, usage would spike, and then everything would slide back toward baseline. The app technically had the capability, but it did not become part of anyone’s life. And in mobile, if you are not part of someone’s life, you are just taking up space on their phone.
So the question that did not get enough respect back then was the simplest one:
Why would someone open this again tomorrow?
Not because they should. Because they want to.
The new game is habit and clarity
The best product conversations I am in now sound less like “What else can we add?” and more like “What is the core job we are actually here to do?” That might sound obvious, but it is a completely different strategic posture. It forces you to zoom in instead of out. It forces tradeoffs. It forces you to admit that more can actually make the product worse.
Mobile makes this especially obvious. People’s home screens are crowded. Their attention is fragmented. Notifications are nonstop. If your app is not reliably helpful in a way that is repeatable, it gets buried or deleted the next time someone does a “why is my storage full?” cleanup. This is where I keep coming back to behavior design thinking. BJ Fogg’s model is simple but brutally clarifying. Behavior happens when Motivation, Ability, and a Prompt converge at the same moment. If the behavior does not happen, at least one of those is missing.
In app terms, that means you cannot motivate your way out of a confusing flow. You cannot prompt your way into a habit if the action is not easy. You also cannot fix a weak core job with a stronger onboarding video. Sometimes the highest leverage “feature” is removing steps, reducing decisions, and letting the user feel progress faster.
Notifications are a trust agreement
For years, product teams treated push notifications like free attention. Now they feel more like a contract. If you interrupt me, it better be worth it. Research on alert fatigue shows a similar pattern across many categories. When alerts are too frequent or not relevant, people start disabling them entirely.
So the strategy question is not “How do we send more notifications?” It is this:
What is the one notification we could send that would make a user feel glad they opted in?
If you cannot answer that, a safer strategy is usually fewer prompts, better timing, and messages tied to an outcome the user already cares about.
AI did not just add capabilities. It changed the questions.
When AI first hit the mainstream, a lot of conversations sounded like “Where can we put AI in the app?” That was feature-first thinking with a new ingredient. Now the more useful question is “Where does AI make this meaningfully easier, faster, clearer, or more useful for a real person doing a real job?”
In practice, I have seen two very different flavors of AI work.
One is sparkly AI. It is the chat bubble or magic button that demos well, but it is not anchored to a specific job. People try it once, then they do not know why they would come back.
The other is quiet AI. It is the part that does not scream for attention. It turns messy input into something organized. It reduces manual effort. It suggests the next best step. It catches errors before the user has to. It takes a workflow that felt like a chore and makes it feel manageable. Quiet AI is rarely the flashiest thing in the app, but it is often the difference between cool and useful.
The teams who do it well tend to treat trust and failure states as core product surface area, not edge cases. Google’s People and AI Guidebook is one of the best practical references for this, especially around setting expectations and designing for when the system is wrong.
On the risk side, I have also seen more teams get serious about what can go wrong when AI touches user data, advice, or decisions. The NIST AI Risk Management Framework is worth reading even if you are not “high stakes,” because it forces you to think in systems, context, impacts, measurement, and governance.
My own strategic filter has become less “we need AI because everyone has AI,” and more:
Is there a place where the user is working too hard, and AI can genuinely reduce that load without increasing confusion or risk?
Sometimes the answer is yes. Sometimes the answer is honestly “no, we just need fewer steps and better copy.”
Roadmaps are less about what is next and more about what you refuse
Another shift I did not fully appreciate until recently is that I spend more time helping teams decide what not to do. For a long time, a roadmap with lots of colored cards looked like strategy. But you can have a gorgeous roadmap that is basically just a wish list with dates. The teams that are winning right now are usually the teams with the courage to say, out loud, “We are not solving that problem this quarter,” and “We are choosing this bet over that bet.”
This matters because user patience is low, and deletion is easy. Benchmarks have shown how quickly users uninstall apps when they do not meet expectations. So when a team gets honest about what survives if you cut half the roadmap, it is not just an efficiency exercise. It is product survival.
Metrics still matter. They just are not the starting point.
I still look at MAUs, DAUs, retention curves. Of course I do. But the most useful teams treat those as signals, not the goal itself.
The deeper question underneath retention is this:
Are we reliably helping someone achieve something they care about?
When you start there, everything else gets easier to reason about. Onboarding becomes about getting to the first meaningful outcome sooner. AI becomes about reducing friction or increasing clarity. Notifications become about timely prompts tied to value. Roadmaps become a set of deliberate bets tied to outcomes, not a buffet of features.
Habit formation research also reinforces this. Habits do not form overnight, and the timeline varies widely depending on the person and the behavior. That is a reminder to design for repeatable value early, not just a great first session.
What I am seeing from the trenches
Over the last few years, my work has mostly looked like untangling products that grew faster than their foundations, turning “we should use AI” into workflows that ship, and helping teams move from opinions to data to decisions. From that vantage point, this strategy shift is not theoretical. I see it when teams say no to features that do not support the core job. I see it when teams stop sprinkling AI in just because it demos well. I see it when teams run smaller experiments tied to real behavior. I see it when teams treat the roadmap like a set of deliberate bets.
It is not flashy work. It is not always postable work. But it is the difference between an app that slowly bloats over time and one that gets simpler, sharper, and more valuable.
Why I am writing this down
I have been noticing these shifts for a while and scribbling notes in random docs and notebooks. This is me starting to pull those threads together in public. If you are building or running an app and you can feel that tension between “let’s ship more” and “let’s be more intentional,” you are not alone.
I am going to keep using these Field Notes to share what I am seeing in SaaS, mobile, and AI-heavy products, including the messy middle, not just the polished case studies.
