What I Actually Did

Context

Zilingo was weeks from filing for bankruptcy. People were leaving daily. Customers were asking whether we would exist in three months. I was running the B2B SaaS manufacturing unit, over 100 factories across six countries. Leadership handed me three goals that normally require three separate initiatives: retain customers, increase IP value for potential acquirers, and give the remaining team a reason to stay.

The call I made

I decided to launch a new product, a machine downtime tracker, in the middle of the crisis. It looked reckless. I believed one focused bet could do the work of three defensive plays.

Approach

• Committed to radical transparency with the team. Updates every three to four days on the bankruptcy risk, the investor conversations, everything I knew.
• Lost three key people over three months. Onboarded replacements within 48 hours each time and built recorded walkthroughs of every design decision, data schema, and integration so we never lost institutional knowledge again.
• Brought every engineer into direct contact with customers. Factory visits, operator conversations. Connection to real impact became the motivating force when nothing else was certain.
• Co-developed the MVP with four strategic customers across geographies. Used those early wins in newsletters to keep the rest of the customer base engaged.

Outcome

Shipped MVP in three months. Twenty-five factories as paying customers within five. Factory downtime dropped by thirty minutes per day, meaningful savings in manufacturing. The product became central to the IP portfolio that drove the acquisition by Solvei8, and the team held together through the crisis became the core of the post-acquisition organisation.

What I learned

Leadership in a crisis isn't about having answers. It's about giving people a reason to keep going when the institution around them is failing.

Context

Our software ran on tablets. Every factory operator needed one to input data. In India, tablets cost around $80 each. An average factory of twenty lines needed roughly forty tablets, so $3,200 upfront capex per factory before they had seen the full benefit of the software. It was the single biggest barrier to closing deals after we had already proven the product worked.

The three things that did not work

• Providing our own tablets. Heavy capex on our P&L, and they didn't always come back in good condition.
• Subsidy deals with Amazon and Flipkart. They wouldn't commit without volume guarantees we couldn't give, given how slow B2B SaaS cycles are.
• NBFC financing on EMI. Interest rates were too high, and financed cost ended up worse than upfront cost.

What worked

I went further upstream. Researched what tablets actually cost to manufacture, and partnered with an OEM already producing tablets for the Indian market. Placed a small custom order with reduced specifications tuned to what our software needed and nothing more. That dropped the cost from $80 to $30-40. Factory upfront capex halved. I hired a front-end hardware person, specified minimum viable specs with our engineering team, and structured the commercial deal so 90% of the sale cost sat with the manufacturer and only 5-7% with us. Kept the hardware off our balance sheet entirely.

Outcome

The adoption barrier collapsed. Sales cycles that used to stall at the hardware question started closing. Piloted with a handful of customers, then scaled the model without becoming a hardware company ourselves.

What I learned

When your customer's biggest barrier to adopting your product is outside the product itself, it's still your problem to solve. And the way you solve it doesn't have to fit your existing business model.

Context

We were serving over 100 garment factories across six countries. New MES competitors were undercutting us on price. Eleven customers were at churn risk, three had already left. My manager wanted to match on price or fast-track feature requests. I pushed back on both.

The call I made

I proposed something counterintuitive: build a new product entirely. Discovery had surfaced something specific. Eight of the eleven at-risk factories were paying for a separate planning tool alongside our operational software. Their real problem wasn't our price, it was their total software spend. A planning tool built on top of our operational platform would give them integrated data no competitor could replicate.

Approach

• Spent two weeks building the case before ever raising it: customer conversations across all eleven at-risk accounts, competitive landscape on existing planning tools, internal coalition across engineering, sales, and customer success.
• Designed the proposal to minimise my manager's risk: sandboxed three-month MVP, team of seven, kill criteria tied to retaining the at-risk cohort.
• Pre-validated demand before the ask. Eight of the eleven committed to trial.
• Co-developed with strategic customers as design partners, using early wins as proof for the broader base.

Outcome

MVP live in three months. Retained eight of the eleven at-risk customers, exceeded the kill criteria. Grew to seventy factories in six months. It became our highest-retention product because the integration with operational data made switching essentially impossible, not through lock-in, through genuine value no competitor could replicate. Contributed meaningfully to MRR growing from $300K to $700K.

What I learned

Influencing upward isn't about winning a debate. It's about doing the work before the conversation, so saying yes feels safer than saying no.

Context

Every sprint we got five to six report customisation requests from factories. Three developers on reports full-time could only ship one or two. The backlog kept growing and my CBO, who was also my manager, had a clear position: standardise. Cut the noise, create a standard set that 80% of customers should be able to use.

The disagreement

His logic made sense in principle. In garment manufacturing specifically, I believed it wouldn't work. Every factory had different departments, workflows, and decision-making mechanics. But arguing from instinct against a reasonable position wasn't going to change his mind. I needed evidence.

Approach

• Analysed six months of report requests and demonstrated there was no consistent pattern. The 80% standardisation target was an assumption, not a finding.
• Ran calls with five industry experts with 20-30 years in garment manufacturing. Each confirmed this industry doesn't standardise reporting.
• Built a prototype self-serve reports builder with a three-month MVP plan and a five-customer pilot. Brought an alternative, not just an objection.
• Framed the conversation as "the data shows standardisation won't solve this, and here's something that will, and here's how we prove it cheaply before committing."

Outcome

The CBO backed the proposal. MVP shipped in three months. Report requests dropped 50%. Developer time on reports went from twenty days per month to seven. Six months later we packaged it as a paid feature and turned a cost centre into a revenue line.

What I learned

Disagreeing upward needs evidence and an alternative that's better than what you're arguing against. Respect their logic. Redirect the mechanism.

Context

Solvei8 (Zilingo's B2B SaaS arm) had grown as a sales-led org: enterprise deals, long cycles, seven days of on-site implementation per factory, and self-discovery of new features close to zero. The economics worked but wouldn't scale to our targets. My job was to figure out whether, and how, we could turn on a product-led motion without breaking the enterprise business paying for it.

Approach

• Segmented the customer base to isolate which use cases were self-serviceable and which structurally weren't. Started with the planning module first, smallest surface area, clearest activation event.
• Rebuilt onboarding around a first-value moment measurable in days rather than weeks: guided in-app walkthrough, pre-configured plan templates, contextual tooltips at decision points.
• Ran the pilot on one module before arguing strategy across the org, with a hard kill criterion: if 30-day retention dropped more than 5 percentage points in the treatment cohort, we'd revert.
• Redesigned sales dashboards around in-app upsell signals so the sales team saw PLG expanding their pipeline rather than replacing it, and repositioned the implementation team from trainers into customer success enablers for enterprise deployments.

Outcome

CAC dropped 15%, acquisition funnel expanded 20%, organic MRR growth roughly doubled for converted modules. NPS held at 91 for three consecutive years through the transformation. The planning tool went fully self-serve within twelve months and became the template rolled across the platform.

What I learned

SLG-to-PLG transitions fail when they're framed as replacements. They work when framed as parallel funnels that trade leads back and forth, and when someone senior defends the sales team's numbers publicly through the transition.

Context

When Zilingo was looking at acquiring nCinga, a Sri Lankan software company, I was asked to lead both the diligence and the integration. Six months on the ground in Colombo. Threefold mandate: retain their key talent, retain every customer, and merge the technology stack and processes into a single organisation without either team feeling like they lost.

Approach

• Ran the diligence pass alongside a focused team: assessed the founding team, the customer book, the codebase, the operational maturity of their platform. Gave leadership a concrete recommendation on structure, valuation, and post-close plan.
• After close, spent the first weeks deliberately not changing anything. Shadowed meetings, ran one-on-ones with junior engineers and QC testers, understood what motivated them and what they feared.
• When an nCinga engineer bypassed our QC process and a Zilingo engineer publicly criticised them on Slack, I handled both privately and used the moment to design a joint QC process both teams owned, rather than imposing Zilingo's on nCinga.
• Built structured cross-team forums so the nCinga team had a real voice in the new organisation, not a performative one.

Outcome

90% employee retention across the integration, against a typical post-acquisition benchmark of 50-70%. 100% customer retention. The combined team became the core of Solvei8's product organisation after the subsequent restructuring, and later carried the SLG-to-PLG transformation.

What I learned

Integration is a trust problem, not a process problem. You can align roadmaps and merge codebases quickly. Getting two groups of people to believe they're on the same team takes time, presence, and willingness to handle the uncomfortable moments directly.

Context

Amazon UK was rolling out a new delivery experience programme for merchant-fulfilled sellers, but adoption was stalling. I was asked to figure out why and shape the go-to-market. My manager was away for the first three weeks and there was no internal consensus. Some teams thought no problem existed. Getting to a real answer meant defining the problem myself before I could solve it.

Approach

• Wrote the SQL myself across 100,000 seller feedback logs, rather than requesting a pull, because the shape of the query kept changing as I understood the funnel.
• Ran forty-one interviews across ten integrators, thirty-one sellers, and six internal EU and US teams. Stratified for variation, not consensus.
• Cold-reached the PMs at Veeqo, Amazon's recently acquired integrator team, for two deep interviews the standard research plan wouldn't have surfaced.
• Built the recommendation around three solution tracks ordered by control and speed, with a financial model projecting the revenue impact of each.

Outcome

The signal that unlocked everything: 75% of merchant-fulfilled sellers used third-party integrators as their primary workflow tool, and spent 80% of their working time outside Seller Central. The programme had been designed against behaviour that didn't exist for this segment. The recommendation was approved by senior leadership after 35+ iterations, shaped the one-year product roadmap, and projected roughly £33M in incremental UK revenue over two years.

What I learned

In ambiguous environments, a PM's job is to build the evidence base that makes the right answer undeniable. No single data source moves people. The synthesis does.

Context

I was on an engagement advising a GCC government body on a $10B digital transformation, making six programmes AI-native across cyber, cloud, data, and infrastructure. Our scope was department-level AI strategy. Through stakeholder interviews I realised the GPU infrastructure question wasn't going to stay departmental. It was going to become a regional problem, and nobody in the room was asking for that view yet.

Approach

• Proposed extending the analysis beyond our brief to a full GCC-level GPU demand forecast. My senior partner was interested but sceptical about timeline feasibility, so I built the initial scaffold over a weekend to prove the shape.
• Sourced an NVIDIA expert to validate assumptions on training versus inference demand curves, the split that mattered most and where I didn't have intuition yet.
• Designed a bottoms-up model with scenario analysis across thirty input variables and five industry verticals.
• Ran regular methodology checkpoints with the partner and chairman so the output had credibility before it was ever presented as a recommendation.

Outcome

The client used the model for budget allocation across the $10B initiative. The chairman noted the regional forecast was exactly where they were heading. The partner published it as a thought leadership piece on the Strategy& platform.

What I learned

The most valuable thing you can do for a senior stakeholder isn't answering their question well. It's anticipating the question they haven't asked yet.