Leading with vision in the cloud era
Shashank Kumar leads product for IBM Cloud's NoSQL databases. His hidden principle — shared here for the first time — is that the best enterprise product is a boring one.
Watch the full episode on YouTube
Executive summary
Shashank Kumar started as an engineer in 2013, moved into data engineering, then into business analysis, and ended up leading product for data engineering and data lakes. A stint at Oracle on the core database program followed, and he now leads product for the NoSQL database portfolio at IBM Cloud — working with six product managers, a worldwide peer group, a design team, and an engineering organisation of more than 300.
Three ideas run through the conversation, and the third is the one he says he has never articulated publicly before.
First: product management is probabilistic, not deterministic.
"Product management and product leaders do not work in a deterministic fashion. We work in a probabilistic fashion. We take bets against the odds or with the odds."
Which means a permanent grey area, and two obligations that follow from it — the appetite to pivot, and the discipline to recognise a sunk cost. "We start investing in something, we keep investing, and then we come to a fixed mindset — we cannot pivot from here, this is what we have done. And the more we keep investing, the more losses we make."
Second: the innovation does not have to come from you. He is direct that this is a widespread misjudgement about the role:
"The idea or the value which a product will create for a customer could come from anywhere. However, the expectation I have from my product manager is that you have to have the capability and knowledge to assess that innovative idea."
Third, the hidden principle — and he flags it as such:
"If my product is boring enough, people don't have to think about it every now and then... You keep innovating underneath, but for them it's boring, because they use it with the same confidence."
"This is the first time I think I have told this on camera."
The story
He graduated in 2013 and went straight into engineering, spending several years there before drifting toward data. What moved him out was not dissatisfaction with the work but a question the work would not answer:
"I keep wondering, okay, why are we doing this? Who will be the beneficiary of these activities?"
That curiosity pulled him into business analysis — the whos and whats and whys, "why are we doing this change, what does it matter, when does it matter" — and eventually into leading the product side of data engineering.
Oracle came next, on the core database program. Then IBM Cloud and the NoSQL portfolio.
The decision to go back for a management degree mid-career he frames as a self-assessment rather than a credential:
"What drives you? What is the next thing that you want to do? ... If you think there is a gap in your skill set — and this is a self-assessment, no one's going to tell you — then perhaps you need further education."
He is deliberately unfussy about the format. Full-time, part-time, correspondence: "what matters is how much you learn out of it."
Key decisions
Decision 1 — Judge ideas rather than generate them
The clearest reframing in the episode, and one that lowers the pressure on product managers considerably while raising the bar in a different place.
His team is not measured on how many ideas they produce. They are measured on the quality of their assessment: "When shall we invest in this opportunity? What does the opportunity cost look like? If not here, where is the opportunity for us?"
The corollary is that other functions genuinely matter, and he makes the case with a comparison rather than a platitude:
"I have seen nice products, high on tech, with a bad design — unsuccessful. And I have seen a moderate product, nothing fancy, a simplified version, with a good design and moderate tech, reaching the heights it should have reached."
Decision 2 — Treat stability as a feature request
In an enterprise setting, a roadmap item does not have to add anything:
"It doesn't have to be a feature enhancement. It could also be a stability request... The stakes are very high. There are large enterprise customers who have trusted us with their larger workloads. And while innovation is important for them, it is also important that they have business-as-usual continuity of service."
Decision 3 — Know when to stop paying
His worked example of getting this wrong is unusually specific, and he tells it against himself.
About five years ago, with AI newly prominent and genuine ambiguity around the terms of use for customer data, his team decided the responsible move was not to train on it. Instead they would synthesise data. He got a team and funding and started.
Six months later, the POC failed — but not for the reason you would expect:
"By the end of the sixth month, when we POC'd this, the AI models had moved a lot... There is a new tech which moved further, and there is something which I was building with my team, and that didn't move further. AI went dynamic and we became more static."
The retrospective is the useful part. The idea was sound when conceived. What he missed was running a parallel track — "I should have kept a balance between the POC approach I was taking, and learning in parallel how this whole industry is moving. So that we could have pivoted at the right time."
Decision 4 — Fix the boring thing customers actually complain about
His example of a market-driven bet is not a new feature. It is the end-of-life experience across IBM's database portfolio — the upgrade path, which customers had been raising through what he calls listening channels, direct and indirect.
"These are really genuine feedbacks, which sometimes also embarrass us, and motivate us as well."
They replaced major-version upgrades with in-place upgrades. The result: up to 4× better than the previous method, rolled out on one product with plans to unify the experience across the rest.
Mental models
Make it boring
The principle he had not said aloud before, and the one most worth stealing.
The instinct is to want an exciting product. He argues the opposite for anything enterprises depend on, because excitement and confidence are in tension. If a customer never has to think about your product, they are never worrying that something is about to break on their side. Innovation continues underneath; from the outside, nothing eventful happens.
He extends it past software: "any business which is typically boring has higher ROI or unit economics."
First principles and inversion
The two mental models he actually deploys. First principles for reasoning up from the fundamentals. Inversion for risk:
"What's the worst thing that would happen here — if we do not do this, or if we do this? Imagine a high stake, where the investment is a lot and then the adoption is not up to the mark."
T-shaped, plus empathy
His answer on whether product managers need an engineering background. They do not — he has seen people arrive from engineering, management, account management and design. What the role requires is depth in one area and breadth across many, plus "some empathy with the customers."
New stacks are built from old learning
A corrective to the assumption that fast-moving categories demand constant novelty:
"Many of the successes I have seen so far are: you continue what you are doing, you keep enhancing what you are doing, give them the stability which they see."
Cloud-ready workloads, in his experience, need "the old stack plus the new stack mix." And "a lot of these modern innovations are happening from previous learning."
Frameworks
Framework 1 — Assessing whether a product will survive
Not TAM and SAM, which he treats as analyst numbers rather than answers. The real questions:
- Who are the actual users, in detail — not just named accounts and high-level use cases, but "a deep understanding of what exactly these customers are doing with my product"
- How many other players are there, and what genuinely differentiates yours
- Who is retained. ARR and retention, not trials. A customer who POCs and leaves is still useful — "we get to learn from them, maybe that use case is not catered" — but they are not the business
Then the sequencing advice: "it's better to start with very niche use cases and then start expanding from there." Understand the customer, define the North Star metric, know the use cases. Only then ask whether there is more opportunity here.
Framework 2 — Market-driven versus top-down, and why GTM decides it
Both kinds of initiative exist in every organisation. Market signals carry a higher success rate "if those signals are strong and you are fast enough and ready enough to go and invest into it."
Top-down initiatives are not worse — but they arrive without market pull, which shifts the burden:
"If you invested without getting strong market signals, then it's your responsibility as a product leader to go and tell the market that there is something which has either a better cost, better performance, better stability, or new ways of doing something."
He is also alert to what a change costs the people already using you. Introduce something new and remove something old, and a customer will reasonably object:
"I have my million dollar business bet on your product, and this is something which you changed."
So backward compatibility and migration become part of the value proposition — and he grants the customer their position: they thought their way of doing it was right, "and perhaps they are right as well."
And neither source is reliably the more innovative one. "It could be either."
Framework 3 — The metrics that decide whether you last
North Star metrics, defined per enhancement, not just per product — because "not every enhancement will return the same set of value to the customers or the same profit to you."
Feature segmentation via the Kano model: must-haves versus good-to-haves, primary versus auxiliary.
Three-layer alignment, which he treats as non-negotiable: "There cannot be a different business strategy and a completely different product strategy. Your product strategy has to align with business strategy, which should be under the corporate strategy."
Unit economics. "If you are unit profitable, there's a high chance in the longer run your business will sustain." Surviving the bad markets is what buys you the long runway.
The rule of 40 as the guiding ratio — growth plus margin summing to 40 or better. His reading of the trade-off is practical: show adoption at scale, or trade margin for adoption, or raise margin and go deliberately niche.
And the failure mode all of this guards against: "imagine a situation where you do all these bells and whistles and forget the main core of the product... your company will not last." Enterprises integrating you into their core architecture need to believe you have a foreseeable future.
Framework 4 — Go-to-market as a budget problem
"GTM is expensive." Which makes it a portfolio decision rather than a per-product one.
His approach: designate one product as the market driver and let the rest travel with it. "It saves a lot of time and money... you're going to say, I have a portfolio, or a platform, which is going to solve this particular thing."
What works, in his experience: partnerships — GSI and ISV — "if you have the right monetisation setup for the partners and the right pricing model." The difficulty is in incentivising and engaging them.
What tends not to work: the wrong channel, chosen out of hope.
"Imagine a luxury good being promoted on a TV ad or through social media influencing, rather than getting into advertisement at a golf course... People target the wrong channel, hoping something magical will happen."
The determining questions are always the same three: what is this product, who is it for, and do those people actually like to buy through that channel.
He also flags the organisational problem underneath all of it — nobody automatically knows what anyone else is doing. "A sales function may or may not know what a product is doing. Sometimes engineering doesn't know what comes six months down the line. Same goes with marketing."
Lessons
The need/want distinction cost him three to four months. His product-driven miss was a cross-selling feature — pre-configured cross products customers could opt into or out of. He surveyed. He spoke to customers he expected would want it.
"This is where it becomes tricky — the difference between a need and a want. We thought they wanted it. Maybe it was not needed."
A survey can confirm that people would like something. It cannot tell you they would have missed it.
His leadership style on GTM is to set context, not instructions. "The context is set. I'm open for options as well. If my team brings me an option, and in principle it looks like something to experiment with, I'm always open... the scope of experimentation in my operating model is always there."
Product, design and engineering sit together in what he describes as a single box, organised around one question: what are we delivering, and for whom.
Feedback that stings is the useful kind. On the end-of-life work: the market's input "sometimes also embarrasses us, motivates us as well. But good feedback is always good."
Actionable advice
If you are moving from engineering into product: the entry requirement is T-shaped knowledge plus customer empathy, not a particular degree.
If you are considering going back to study: run the self-assessment honestly. Drive plus a real gap justifies it; the format matters far less than the learning.
If you lead product managers: hire and coach for the quality of their assessment, not the volume of their ideas.
If you are six months into something that is not working: ask whether the world moved while you stood still, and run a parallel track watching the field so you can pivot on time rather than in hindsight.
If you are launching top-down: budget for awareness. Without market pull, the education is your job.
If you are choosing a channel: ask whether your buyer actually purchases that way, and be willing to conclude they do not.
If you want durable revenue: make it boring.
Final thoughts
"Make it boring" sounds like modesty and is actually a strategy, which is why it is worth ending on.
Everything else in this conversation points the same way. Stability requests belong on the roadmap alongside features. Modern stacks are mostly old learning rearranged. The best bet he describes making is not a new capability but a better upgrade path. Unit economics and the rule of 40 decide whether you are around in five years; bells and whistles do not.
That is not an argument against ambition. He runs a portfolio inside one of the fastest-moving categories in software and is candid that the pace outruns everyone's ability to innovate against it. It is an argument about where the ambition should be directed — underneath the surface, where the customer never sees it, so that the thing they do see stays reassuringly uneventful.
An enterprise customer has bet their architecture on you. The highest compliment they can pay is to stop thinking about you at all.