Frame the job
What is the user actually trying to get done? What must work for this product to be useful at all?
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.
Start with the user, friction and assumption worth testing.
Keep the core journey. Cut what does not improve the learning.
Use direct observation and session recordings, not assumed behavior.
Iterate, simplify, scale or stop based on what the evidence says.
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.
What is the user actually trying to get done? What must work for this product to be useful at all?
Keep the critical path. Defer everything that makes the prototype bigger without making the learning better.
Run the journey myself, then put it in front of other people instead of assuming the flow is obvious.
Use behavior, friction and failures to reprioritize the next iteration, rather than defending the original design.
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.
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.
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.
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.
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.
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%.
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.
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.
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.
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.
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.
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.
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.
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.”
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.
Question: How much of a business process can be expressed as one composable workflow, without forcing people to stitch together a dozen disconnected tools?
Question: Can an AI front desk handle useful inbound and outbound business conversations, not just demonstrate a voice model?
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?
Question: Could synthetic populations become a useful pre-research layer for testing how different consumer groups might react to a decision, message or scenario?
Question: Can capturing a thought be nearly frictionless while the organization, summarization and action extraction happen after the capture?
Question: Could a dating product be designed around depth and a more intentional journey rather than maximizing profiles, swipes and superficial choice?
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.
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.
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.
Even with AI-assisted coding, every feature creates more states, failure modes and maintenance. “Not now” is still a product decision.
It exposes assumptions that survive perfectly well in a document. You learn much faster when the idea has to behave.
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.
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 ↑