🎧 Listen to the full episode here.
You can have a technically sound proposal and still struggle to get leadership buy-in. Perhaps a platform needs replacing, the architecture is holding the business back, or there is an opportunity to introduce AI. You know what needs to change, but how do you convince leadership that it is worth the investment?
The challenge is not always explaining the technical problem. It is building a business case that shows how the proposed solution supports the company's goals, why it matters now, and what value it will deliver.
In a recent episode of The Open Podcast, Sander Mangel spoke with Elena Leonova, CEO at OneRank.io, and a product leader with experience at Magento, BigCommerce and Spryker, about how product and technology teams can make proposals that resonate with leadership. They discuss how to align product strategy with business priorities, evaluate the return on technology investments, and decide whether initiatives such as platform modernization or AI will move the business forward.
‍
Why product strategy must align customer needs with business goals
Product teams are often taught to start with the customer, but Elena's experience taught her that this is not enough on its own. After years in product leadership, she noticed that 2 companies in the same industry could benefit from different product decisions, even if their customers had similar needs. A feature that makes sense for one company may do little for another, depending on where the business is heading.
As Elena puts it, “you might build something that customers want, but it will never make your company successful.”
Elena describes strategy as the path between point A, where a company is today, and point B, where it wants to be in 2 to 3 years. The investments that make sense along that path depend on the company's stage, financial situation, and next milestones.
‍
The right investment at the wrong time is still the wrong investment
Elena shared the example of a product leader who wanted to refactor an ageing platform to prepare it for AI. Despite repeatedly presenting the case, she could not get leadership to approve the initiative. At first glance, the decision seemed straightforward. The technology needed attention, and the company wanted to embrace AI. So why would leadership stand in the way?
The missing context was ownership. The company belonged to a private equity firm and was approaching the point at which it expected to sell the business or take it public. A fundamental platform refactor would take years and spend significant resources without an intended return.
Once the product leader understood that context, she reconsidered her proposal. Instead of rebuilding the foundation, she explored ways to introduce AI capabilities without making a fundamental change. The business could still move forward without committing to a long-term transformation that did not fit its immediate priorities.
As Elena explains, the important question is not simply whether a technical decision is right, but “is it the right thing right now?”
‍
What to know before recommending a solution
You will not always have access to a company's financial plans or internal strategy, particularly if you are an external partner. But that does not mean you have to walk into the first meeting without context. Elena points out that public information can already tell you a lot. Who owns the company? Is it founder owned, publicly listed, venture capital backed, or owned by private equity? How mature is the business, and what might its next stage look like?
This can help you form a more informed view of its priorities before you start making recommendations. That research should be followed by conversations with the people responsible for the business. Where do they want to be in the next couple of years? What are their biggest challenges? What constraints are they working with?
It is also important to speak with people beyond your usual contact. An ecommerce manager might ask for new marketing tools to improve conversion, while the CFO is concerned about margins. These priorities are not incompatible, but addressing one without understanding the others can lead you towards the wrong solution.
Sander shared an example of a company that approached him wanting to replatform its webshop. During the conversation, it emerged that the company was also considering acquisitions, each bringing its own IT infrastructure. Replacing the webshop without considering how those businesses would fit together risked solving a small part of a much bigger problem. The recommendation was to step back and look at the broader IT landscape first.
That is the value of asking better questions before recommending a solution. Sometimes the best proposal is to delay the project everyone came to discuss.
‍
Why you should stop prioritizing wishlists
Most product and technology teams have a long list of requests. Teams then try to organize these requests into must haves, should haves, and nice to haves. According to Elena, the problem is that prioritizing a wish list does not tell you whether the items on it will move the business forward. You need a more meaningful starting point.
Elena identifies 4 business drivers to consider when evaluating an initiative: growing revenue, optimizing costs, reducing risk, and adding strategic leverage.
The right priorities depend on which of these drivers matter most at a particular time. A company might need to improve conversion to grow revenue or it might get a better return from reducing the cost of serving existing customers. This also changes how you think about features for existing customers. Growth does not always mean acquiring more people. Improving retention or making customer service more efficient can create value without bringing in a single new customer.
When you present an initiative, the important part is to connect it to the business outcome. As Elena explains, when she presented product investments to a board, the questions that mattered were: "What is going to be the return and how quickly? And what are the early signs that you have that it's going to happen?"
These questions force one to move beyond the assumption that a feature will automatically deliver value simply because it has been built.
‍
How to apply the same thinking to AI
Many businesses are looking for ways to introduce AI into their products and operations, but the starting point is often the technology itself. Could we add a chatbot, automate customer service, or generate content with AI?
Elena has seen how easily this turns into a race to add features without a clear commercial purpose. AI might be able to perform a task, but it does not automatically make it the right or most economical way to do it.
Sander shared the example of a company who was looking to automate customer service because it received too many questions about orders. Digging into the problem revealed that its systems were not connected. Without access to reliable order information, an AI assistant would struggle to give customers useful answers. So in that situation, the underlying data and integrations needed attention first before the proposed AI solution could deliver what the business expects.
As Sander puts it, “You can want all the features in the world, but if your data is not in the right shape, we’re not going to do anything.”
There is a commercial risk too. AI usage can introduce ongoing costs that increase as customers use a product more extensively. If the feature does not create enough value to justify those costs, margins suffer. And then if customers did not need the feature in the first place, the business may not have reason to charge more for it.
In that case, Elena says, you are “adding something that is expensive for nobody’s good.”
The point is not to avoid AI. It is to apply the same discipline to AI investments as to any other product decision.
‍
The goal is to make decisions that move the business forward
AI is also making it easier to turn an idea into a working prototype before committing to a full implementation. The one caveat though is that a prototype only answers certain questions. As Sander and Elena discuss, the business case needs to be tested alongside the technical one. Before investing further, identify the assumptions behind the proposal, the outcome expected, potential return, and timeframe in which you expect to see it. Then use the prototype to gather evidence.
“Instead of just asking would it technically work,” Elena says, “you also need to ask, would it actually convert, would people buy it?”
The same principle applies after launch. Measure what happens and compare the results with the original assumptions. If the expected value does not materialize, this gives the team the basis for adjusting its approach rather than continuing to invest simply because the idea has already been approved.
Ultimately, proposals that resonate with leadership do more than explain what technology can do. They connect a proposed investment to the direction of the business, acknowledge the constraints, and evaluate the expected return.
The goal is not to get every feature on the roadmap approved but rather to help the business make better decisions. Building the right thing is only half the job. You also need to know why the business needs it, why it needs it now, and what success will look like when you are done.
