Product · Strategy · Growth

I find the problem underneath the ask.

Then I shape the simplest product, process, or experiment that can solve it, put it in front of people, and use what happens to decide what comes next.

Product loop
01 · Frame
Define the job

Start with the user, friction and assumption worth testing.

02 · Prototype
Make it testable

Keep the core journey. Cut what does not improve the learning.

03 · Observe
Watch what people do

Use direct observation and session recordings, not assumed behavior.

04 · Decide
Prioritize the next move

Iterate, simplify, scale or stop based on what the evidence says.

How I build

Product judgment before feature volume.

Across work and side projects, I start with the job rather than the solution. At work, I shape product direction with engineering, leaders and partner teams. In my own experiments, AI-assisted development shortens the distance from hypothesis to usable software.

01

Frame the job

What is the user actually trying to get done? What must work for this product to be useful at all?

02

Choose what not to build

Keep the critical path. Defer everything that makes the prototype bigger without making the learning better.

03

Experience it as a user

Run the journey myself, then put it in front of other people instead of assuming the flow is obvious.

04

Change the product

Use behavior, friction and failures to reprioritize the next iteration, rather than defending the original design.

A small example that changed how I think

I had designed an interaction around dragging an item. When I watched people use it, several tried clicking instead. The problem was not that users had failed to understand my design. The design had failed to match what users expected.

“The flow is obvious.”
Watch what people actually do.
Professional product work

Product work across enterprise systems, growth and user behavior.

Some of my roles have also spanned strategy and programs. This portfolio focuses on the product work within them: vision, discovery, prioritization, requirements, cross-functional shipping, adoption and iteration against real user behavior.

Target
Official role: Senior Program Manager, Strategy & Ops · Product Manager for Idea Workspace + product work across AI decisioning and enterprise platforms
Enterprise product
1,500+ideas submitted through Idea Workspace
50+campaigns and innovation initiatives hosted
1,000+ideas processed by AI evaluation
1,200+users of AI Fluency Pathways

Idea Workspace

Product vision: make Idea Workspace the single place where innovation work can start, be evaluated, progress and reach an explicit outcome. Team members submit ideas; teams run campaigns and hackathons; AI and human evaluation happen in the same system; and promising ideas move through validation, leader review, build, scale or closure.

What I own: product vision, roadmap and prioritization for the platform, working with engineering and stakeholders to shape the workflows behind the broader Idea Pipeline. The product has supported 1,500+ ideas across 50+ campaigns and initiatives.

AI Idea Evaluator

Starting question: “Can we use ChatGPT to evaluate an idea?” I reframed that into a broader product question: can AI provide a scalable first layer of decision support before scarce leader attention is used?

I built the first prototype, validated it with 100+ senior leaders, took it through senior leadership reviews, and helped turn it into an API integrated into Idea Workspace. It has now processed 1,000+ ideas and acts both as the first evaluation layer and as an additional perspective for human evaluators.

Innovation spaces platform

Product problem: two physical experimentation spaces contain multiple zones, devices and eligibility rules, so booking and device access cannot be handled by a simple calendar.

I own the product side of the platform being built to manage space booking, zone eligibility, device provisioning and borrowing, shaping the end-to-end rules and experience with engineering. In parallel, we are identifying reusable patterns that could inform other internal products.

Supply-chain simulation

Problem: a powerful forecasting engine already existed, but analysts and planners depended on the team that built it to run simulations, creating turnaround measured in days.

As part of a Product Fellowship alongside a senior product manager, I worked on the user-facing layer that made simulations accessible on demand, then focused on rollout, onboarding, user requirements and the next iteration. Turnaround dropped by up to 90%.

AI Fluency Pathways

Problem: team members needed a simple way to understand where they stood on AI fluency and what they should learn next. I built a lightweight AI-assisted assessment product that maps responses to personalized learning pathways.

More than 1,200 team members used it. User and leader feedback drove additions such as result exports, Slack sharing and aggregate tracking through Power Automate.

Personalized Slack Outreach

Problem: broadcast email and channel posts were easy to send but often easy to ignore. I built a small UI connected to Slack workflows where a user can paste a recipient list, format it and trigger individualized 1:1 outreach at scale.

In tracked use cases, conversion improved by 300–400%, and the tool was reused by teams across India and the U.S. The point was not the complexity of the software; it was removing friction from a repeated communication job and measuring whether behavior changed.

Sometimes the answer is not a product

The original onboarding idea was a week-long live program. Looking at the underlying job changed the solution: a semi-autonomous five-week journey, beginning before joining and continuing after, largely orchestrated through Power Automate.

The pattern I care about is not “build software.” It is solve the job with the least unnecessary machinery.

workat.tech
Product & Program Manager · Growth lead for a software engineering interview-prep platform
0 → scale
30k → 100k+monthly platform usage
8k → 45kregistered users
₹0paid acquisition
Operating belief: quality was not separate from growth. The goal was to make the product and surrounding experience genuinely useful enough that the right users returned, shared it and brought others in.

Jobs as acquisition

I hypothesized that curated software-engineering jobs could solve a real user need while also becoming a top-of-funnel acquisition surface. We validated the idea before investing further, then built the Jobs product. It generated 400,000+ clicks and became a major registration driver.

Core-product growth

Led activation and engagement experiments across competitions, community programs and in-product loops, contributing to a 25% MAU increase and 20% month-over-month growth.

Public Profiles

Recurring community feedback pointed to a user need around identity and proof of work. I carried the Public Profile product from feedback through design, build and launch, one of several intuition-first, data-validated experiments that compounded into organic growth.

Community as product distribution

Built community-led growth channels from scratch, growing Discord to 10,000+ members and LinkedIn from under 3,000 to 30,000+ followers in ten months, feeding the platform's organic acquisition loop.

A principle I carried forward from workat.tech

We grew without paid acquisition by treating product quality, usefulness and community experience as part of the growth system itself. That shaped how I think about product work today: distribution matters, but the strongest loop starts with something people find worth using and sharing.

“Growth is a layer on top.”
“Quality creates pull.”
Blupe Labs · independent builds

Six different questions. Working software as the test.

These are deliberately not presented as six startups. Some are usable products, some are MVPs, and some are experiments I chose not to push further.

Voice AI

Voice by Blupe

Question: Can an AI front desk handle useful inbound and outbound business conversations, not just demonstrate a voice model?

I focused on: call flows, campaigns, business context, transcripts, responsiveness and usable operator workflows.
Agentic concierge

Envoy

Question: What if a user could state a real-world goal and an agent could search, contact businesses and bring back the answer instead of handing the research back to the user?

Status: basic MVP. Enough to test the interaction model, not something I chose to scale further.
Why it mattered: it moved the agent from answering questions to taking actions across the offline economy.
Behavioral simulation · WIP

Simulations

Question: Could synthetic populations become a useful pre-research layer for testing how different consumer groups might react to a decision, message or scenario?

I focused on: target-audience definition, generated personas, scenario response and aggregated behavioral patterns.
Longer-term idea: ground synthetic personas in real customer metadata rather than generic model assumptions.
Personal productivity

Notes

Question: Can capturing a thought be nearly frictionless while the organization, summarization and action extraction happen after the capture?

I focused on: typed and spoken capture, summaries, action items and a simple primary journey.
Product constraint: the feature set matters less than whether capturing something feels faster than avoiding the app.
Consumer product · Beta

Ekam

Question: Could a dating product be designed around depth and a more intentional journey rather than maximizing profiles, swipes and superficial choice?

Why I built it: to work through a complete consumer product experience, from proposition and landing page to the actual interaction flow.
Reality: the prototype works, but the current architecture is not designed for large-scale use.
Product judgment + prototyping leverage

Implementation can be assisted. Product judgment cannot be outsourced.

What I own as a product person

Frame the problem and user job. Form the hypothesis. Define the core journey. Prioritize what matters now and what can wait. Shape requirements and trade-offs with engineering and stakeholders. Put the product in front of users, understand adoption and friction, and decide what the next iteration should be.

What the builder flavor changes

In independent experiments, AI lets me prototype directly instead of waiting for implementation bandwidth, which compresses the loop between an assumption and evidence. I do not present that as software-engineering expertise. I use it as a product tool: a faster way to test, learn and make better decisions.

Working principles

What years of building and shipping changed for me.

01

Users do not experience your intention.

They experience the interface in front of them. Direct observation and tools such as session recordings are often more useful than another round of internal reasoning.

02

Prioritization becomes real when building has a cost.

Even with AI-assisted coding, every feature creates more states, failure modes and maintenance. “Not now” is still a product decision.

03

A working prototype changes the conversation.

It exposes assumptions that survive perfectly well in a document. You learn much faster when the idea has to behave.

04

Stopping can be a valid result.

Not every prototype deserves a company around it. An experiment has paid for itself if it gives you a useful answer about the problem, technology or user.

Product portfolio

Less interested in presenting what I made. More interested in showing how I decide what deserves to be made.

Across professional product work and independent experiments, the pattern is the same: understand the job, choose the smallest useful intervention, put it in front of people, and let reality improve the next decision.

Back to the top ↑