Concept-to-MVP Product Strategy

Turn ambiguity
into a product.

We work with teams who have an important idea, a pile of research, or an emerging technology opportunity, and still need to figure out what to actually build. We help you get from unclear to ship-ready.

Discuss a project → How it works
About

The work between
the idea and the build.

Most teams arrive at product development too early, before the problem is well-defined, the users are understood, or the constraints are visible. The result is prototypes that don't survive contact with reality, and MVPs that answer the wrong question.

Tilted Ground works in the gap between insight and execution. We structure the problem, define what "done" looks like, and design the smallest version of the product worth building. We run on 15+ years of product strategy across fintech, education, health, and AI governance, in environments where the stakes are real and the room for error is small.

Structure first.

Before wireframes, before user stories: who is this for, what decision does it enable, and what is the minimum viable version of that? These questions save months.

MVP, not prototype.

A prototype proves technical feasibility. An MVP tests whether the product creates value for a real user in a real context. We help you build the second one, not just the first.

Reasoning, not templates.

Complex problems resist frameworks. We bring thinking, not playbooks — because the right structure for your problem is the one built for it specifically.

How We Work

Three stages.
One clear output.

Every engagement moves through the same arc: understand the real problem, design the right product, and define the smallest build worth testing. We work with you at every stage, or join at the one where you're stuck.

01

Find

We map the problem space before touching any solutions. Who is this for? What decision are they trying to make? What constraints are non-negotiable? What have previous attempts missed? This is the work that determines whether the product is worth building at all.

02

Define

We translate insight into a product concept. User journey, information architecture, core flows, key decisions. What does the system need to do? What does it explicitly not do? We produce a product brief clear enough that engineering can act on it without ambiguity.

03

Learn

We scope the MVP — the smallest version of the product that can generate meaningful signal. We design the prototype, define the test conditions, and structure how you'll know what you learned. The goal is a product that creates value, not just one that exists.

When we're useful

Come to us before
the requirements are obvious.

You have important research but no product concept

The evidence is solid. The insight is real. But "what should we build?" hasn't been answered yet.

You have a feature list but no user journey

Stakeholders have opinions. Engineers have questions. The product spec doesn't exist or doesn't hold together.

You have a technology but no use case

A capability is in hand — AI, a dataset, a platform. Where it creates genuine value for a real user hasn't been defined.

You have a brief but not the right brief

Someone wrote down what to build before the problem was understood. Building it faithfully would be a mistake.

You've tried once and the pilot didn't land

Something built and tested. It didn't work, or didn't tell you what you needed to know. The question is why.

You need to show the path before you can raise the money

The funder wants to see a product strategy before committing. The team needs help articulating what they're actually building.

Selected Work

What the work
actually looks like.

Four projects where the real job was not building the product — it was figuring out what to build, and why.

AI Governance Product Strategy
Digital Trust Council
AI Trust Index

The challenge. Substantial research existed on AI trust — no product architecture did. Multiple possible audiences, fragmented evidence, and rapidly shifting systems made the right structure non-obvious.

What we shaped. Product layer separation (model / configuration / use-context), user and JTBD definition, evidence architecture, and a clear MVP boundary distinguishing decisions that had to be made now from those that could wait.

The goal was not to eliminate complexity — it was to structure it well enough for a product to emerge.
Education Technology Product Strategy
HelloFuture
Partner Analytics Platform

The challenge. A youth-development organisation believed it needed a more sophisticated partner portal. The solution had been defined before the problem was understood.

What we shaped. Separated reporting from analytics from future operational workflows. The real bottleneck was upstream data quality, not interface sophistication. Scoped a simpler analytics MVP and surfaced the need for a longitudinal data model.

Don't build a platform before proving the underlying reporting creates value.
Health & Disability Product Strategy
Behaviour Momentum India
Marg — Autism Support App

The challenge. Parents of newly diagnosed children navigating emotional overload, misinformation, and complex treatment choices — across regional languages, with limited health literacy, and no clinical support structure.

What we shaped. Target user definition, free-to-paid journey, trust-building onboarding, AI-assisted content and voice intake, phased MVP scope — all grounded in the emotional and behavioural context first.

Start with the emotional context. Technology choice follows from that.
Learning Systems Product Strategy
Art of Living
Intuition App

The challenge. An existing app with a large stakeholder-generated feature wishlist. No learner journey, no progression architecture, no clear answer to what the product was trying to accomplish.

What we shaped. A 40-day learner progression, role differentiation (child / parent / teacher / admin), age-appropriate content pathways, a Skills Ladder as the organising spine, and a phased development plan in place of the feature list.

A learning app is a progression system, not a feature collection.
Resources

Thinking before
the build.

Field guides and frameworks on product strategy, data architecture, AI governance, and the decisions that determine whether a product is worth building at all.

Series 01

Funding AI that works

A funder's toolkit for backing AI in mission-driven contexts. Frameworks for readiness assessment, evaluation criteria, scale strategy, and documented case studies.

4 guides & frameworks Explore the series → Series 02

Designing the system underneath the product

Who owns the system controls the intervention. Five field guides on data ownership, modular systems, content architecture, localization pipelines, and outcome metrics.

5 field guides Explore the series → Series 03

Building portfolio services that actually work

How funders, accelerators, and foundations can build support infrastructure that reaches portfolio organisations — from what VC firms got right to mentor network design.

4 field guides Explore the series →
Explore all resources →
Shruti Keerti, Founder of Tilted Ground
Founder

Shruti
Keerti

Founder, Tilted Ground

I've spent 15+ years doing the work between the idea and the build. At PayPal and eBay, in consumer fintech and marketplaces at scale. Then in education and social impact — at Udacity, Hapara, Byju's, and Quest Alliance, organisations working on learning at scale, often in under-resourced contexts.

The consistent thread across all of it: the hardest part is never the technology. It's turning something complex and ambiguous into a product that works for real people in real conditions. Tilted Ground is built around that specific work.

PayPal eBay Udacity Hapara Byju's Quest Alliance 15+ years
LinkedIn Email
Point of view

The problems
we choose matter.

Tilted Ground is sector-agnostic but not problem-agnostic.

We are drawn to complex, consequential problems — in education, health, AI governance, climate, and other systems that shape people's lives at scale. Not because we limit ourselves to these areas, but because they are where the intersection of product clarity and meaningful stakes tends to be most live.

We believe technology is most useful when it strengthens human agency rather than substituting for it, and when product decisions account for the institutions, incentives, and environments in which technology actually operates.

The work we turn down is rarely about sector. It is usually about whether the ambiguity is real — whether there are genuine decisions to be made — or whether the brief has already been written and what is really being asked for is execution support.

The name carries the theory.

Ground is foundation — systems, institutions, the existing order. Tilted is the deliberate act of shifting who holds leverage. Built to distribute power.

Have a problem that
hasn't become a product yet?

If you're sitting on an important idea, a pile of research, competing stakeholder needs, or an emerging technology opportunity — and still asking "what should we actually build?" — that's usually where Tilted Ground is most useful.

Start a conversation → Email Shruti