mk.Mani Keerthan
02 / ONTOLOGOSJK TECH · 0→1 ENTERPRISE PRODUCT

TECHNICAL POSSIBILITY → PRODUCT CLARITY

Build enough
to make the
next decision.

A year of technical thinking.
A product that needed to become tangible.

Ontologos is an enterprise AI/data platform for fragmented data, semantic mappings, quality, and lineage. I defined working flows with backend and data engineers and built the integrated POC in roughly two weeks.

Explore the product decision
~1 yearInternal concept before this workStarting context
~4 weeksDiscovery and functional buildingApproximate project interval
v1.0Varsity Brands client / partnerShared outcome I contributed to
ONTOLOGOS / SCHEMA REVIEWSource → Relationship → Target
Ontologos schema-review interface with a source field, target attribute, relationship path, and metadata inspector

Supplied Ontologos screen. The visible mapping and metadata make the product question concrete; interface values are not reported outcome metrics.

View full screen

THE PRODUCT DECISION

The prototype was
a way to find out.

Build enough of the experience to expose requirements, examine behavior, and move the product conversation forward.

  1. 01 / UNDERSTAND

    Learn the domain.

    Stakeholder interviews, enterprise-data concepts, use cases, and workflows.

  2. 02 / MAKE TANGIBLE

    Build an integrated flow.

    Available APIs, metadata requirements, engineering collaboration, and rapid iteration.

  3. 03 / EVALUATE

    Give people something to inspect.

    Internal alignment, executive presentations, and progress toward customer validation.

THE DECISION BRIEFOwnership · Evidence · Trade-offs · Outcome
Contributing outcome~4 weeks

Toward a client-backed product direction

Context

A year of technical thinking needed a product expression.

Ontologos had existed as an internal enterprise AI/data-platform concept for roughly a year. The team had substantial technical thinking, but product clarity, usability, differentiation, and customer readiness remained difficult. The challenge was not simply to give the concept a cleaner interface. It was to make the workflows concrete enough that stakeholders could understand the value, engineers could identify requirements, and a customer could evaluate the emerging product.

My ownership

I took initiative around the product layer.

I spent approximately the first two weeks learning the domain, interviewing stakeholders, understanding workflows, researching enterprise-data concepts, and clarifying use cases. Over the next two weeks, I built a functional integrated experience, iterated workflows, collaborated with backend and data engineers, integrated available APIs, and validated the evolving product. I defined what the user and product layer required. I did not architect the backend.

Evidence

Working flows exposed questions abstract discussions could not settle.

The workflow spans discovery, profiling, remediation, schema mapping, ETL, reconciliation, and governance. We designed around approximately 12 domains, up to 20 entities per domain, and up to 66 attributes per entity. Differently named fields—such as CRM customer_id, SAP business_partner_no, and store user_id—can represent the same Customer concept. Making those relationships visible required clear metadata, provenance, and source-to-target behavior.

Product judgment

Build enough to remove uncertainty.

The central decision was to make enough of the product work to support better decisions, rather than continue debating the concept only in the abstract. The prototype served as a shared product definition. It helped clarify metadata requirements, workflow behavior, API needs, and how complex enterprise concepts should appear to users. Its value was the decision cycle it enabled, not the amount of code or the polish of individual screens.

From concept to an evaluable product
IntervalFocusDecision enabled
Weeks 1–2Domain learning and stakeholder interviewsClarify use cases and workflows
Weeks 3–4Functional experience and API integrationInspect data, behavior, and technical gaps
Next validationReal enterprise data with v1.0 partnerEvaluate the product direction

Decision summary reconstructed from Mani’s account. Original artifact not supplied.

PRESENTATION PROTOTYPE / WANDER

Make the relationships visible.

Ontologos is the product. Wander is the name I used for this AI-assisted presentation prototype. The screen expresses an ontology through connected entities, attributes, and a contextual inspector—making complex concepts easier to examine in a product conversation.

WANDER · AI-ASSISTED PRESENTATION PROTOTYPE BY MANI
Wander presentation prototype with a market ontology linking orders, fills, settlements, accounts, and risk rules

The prototype’s Wander branding is preserved. Its market scenario illustrates the presentation; it does not redefine Ontologos’s customer or establish a production deployment.

View full prototype screen

Trade-off

Choose a concrete learning surface over abstract completeness.

The approach prioritized an integrated experience built with available APIs and engineering collaboration. It did not imply every underlying technical question had been solved. Cursor, ChatGPT, Lovable, and AI-assisted development accelerated execution, but they were means rather than the product thesis. Detailed scope exclusions and production-hardening trade-offs need more context. I do not equate a functional prototype with a fully validated enterprise platform.

Influence & execution

Give internal and customer conversations a shared object.

The working product made the direction concrete enough to align internal stakeholders, present to senior and C-suite leaders, and move toward customer validation. Backend and data engineers remained essential partners. Rather than describing an interface handoff, the execution story is a feedback loop between workflows, available data, API behavior, and stakeholder review. The product layer made requirements easier to examine and discuss.

Outcome

The concept moved toward a client-backed SaaS direction.

In approximately four weeks, I helped convert a long-running internal concept into a client-backed product direction. Varsity Brands became the v1.0 client / partner using real enterprise data. That is a shared business outcome to which my work contributed. I do not claim to have closed the customer, independently created the commercial relationship, or designed the underlying data architecture.

Learning

A prototype can be a product-management instrument.

The important shift was from discussing what the product might be to evaluating how it actually behaved. Design and technical prototyping gave me an execution advantage: I could make ambiguity visible and help the team act on it. Customer readiness still requires evidence beyond internal conviction. The specific feedback that created v1.0 confidence is the next part of this story to substantiate.

THE REASONING BEHIND THE RESULT

What made the decision difficult?

Inspect ownership, evidence, alternatives, technical constraints, and the limits of the result.

CONTINUE THROUGH THE WORK