Lessons learned: how designing complex operational platforms leveled up my product strategy
So many product conversations start with features: what do customers want, what are competitors doing, what should we prioritize, and so on. Obviously, these are very important questions that should be addressed.
But after spending years modernizing complex operational platforms, I’ve also found that some additional product lessons come from understanding how entire systems work. When zooming out, a feature is part of a system. And you can’t focus on the individual pieces while ignoring the big picture. (Having jumped into recipes in the past without reading the whole thing first, maybe I should have known this, but that’s another conversation…)
Anyways, to elaborate:
The mistake of optimizing features instead of systems
While many teams focus on solving individual requests such as new workflows, reports, or features, this can create some long-term risk. Over time, this can create products that meet immediate needs, but become increasingly difficult to maintain, scale and, evolve.
How much are we valuing scalability and longevity as the business continues to grow? Hopefully, a lot.
So instead of asking about “next features”, try this one: what workflow are we trying to improve? And taking it further, where are all the touch points where there is opportunity for improvement?
Here’s how
Understand the flow before the feature
Users and customers do not experience your products as a collection of features and they certainly don’t care to hear your excuses about why you had to do things a certain way.
They have their boss asking when they’ll be done with xyz, so they’re focused on finishing up that workflow. That’s it.
So, at Alaska, when we mapped workflows across systems, teams, and processes, recurring issues emerged:
Duplicate work
Manual handoffs
Conflicting information
Bottlenecks galore
So of course initial feature requests became much less compelling when we saw the actual symptoms of workflow problems.
By improving the flow itself, we solved multiple customer and business needs at once.
Treat data and integrations as product decisions
I’ve seen many product leaders treat engineering teams as production rather than strategic partners. Specifically, data models, integrations, and system architecture are “technical concerns”.
In reality, these directly impact customer experience. Reliability, automation, personalization, and decision-making all depend on trustworthy data and connected systems. Let’s not lose sight of what’s important about the people we’re serving: their jobs literally depend on it. They’re often giving us money to make sure of it, lots of it, so we owe them to deliver.
When we invested in reducing operational friction, confidence in data, creating more seamless user experiences, and creating a platform that supported future growth, we were making product decisions that grew customer trust and opened the door for new customer value.
Which leads me to…
Prioritize scalability over short-term convenience
One major lesson from large-scale system design is that every short cut eventually became someone else’s problem. This is in direct conflict with how I approach work in general: don’t burden your colleagues with your incompetence or laziness!
Temporary workarounds, duplicated logic, and disconnected systems can accelerate delivery in the short term, but they often create technical debt that slows future innovation and limits growth.
As products evolve, customer expectations change: new workflows emerge and that means new integrations become necessary. What works for hundreds of users may not work for thousands.
Instead of asking:
What's the fastest way to solve this problem?
How quickly can we ship this feature?
We can ask:
Will this solution support future customer needs?
How easily can this capability evolve as the business grows?
Does this strengthen or weaken the foundation we're building?
These decisions required more upfront effort, but they reduced future maintenance costs, accelerated delivery of new capabilities, and prevented teams from repeatedly solving the same problems.
Most importantly, they created a platform that could support growth, because that is ultimately a product concern.
If I’m at the helm, I need to make sure that products endure and are designed to evolve alongside the customers, instead of having to be rebuilt every time the business reaches its next stage of growth. Assume you’ll be successful and anticipate, anticipate, anticipate.
Remember to zoom out and look at patterns
Working with large operational systems reinforced the importance of maintaining a comprehensive view of the ecosystem. Before prioritizing a solution, it's critical to understand:
How does this affect adjacent workflows?
What systems and people depend on it?
Does a similar capability already exist elsewhere?
Could solving this problem also address related challenges?
When you understand the broader system, patterns begin to emerge. This approach not only creates more value, but also reduces complexity, improves consistency, and prevents the accumulation of unnecessary technical debt. When you understand the system well, you know how to solve the right problem and, hopefully, how to solve a few problems with one solution!
Maintain a competitive advantage
Many companies compete through features, because they are visible and easy to market. The problem is: they’re also easy to copy. (Do you have any idea how many times I’ve reverse engineered someone else’s feature?)
On the other hand, building a robust foundation allows us to deliver new capabilities faster, adapt to changing customer needs, and create experiences that can’t be replicated (at least not quickly).
In conclusion
Look, I don’t belong in the desert snack section of the grocery store (read: I’m not a ding dong), so I’m well aware that building comprehensive foundations and avoiding tech debt are not always realistic in a fast-paced competitive environment. However, after working on an in-depth technical project, I’ve learned so much about why that work is important. What I take with me going forward is that these questions and techniques can help a product team find the right balance when competing priorities are pushing strategy in different directions.