'01234567890123456789
Building the foundation
Started turning computer science fundamentals into practical products and learning how strong execution begins with a clearly framed problem.
UTKARSH
Product,AppliedDifferently.
15+Client projects
coordinated
coordinated
45+Discovery
conversations
conversations
CuriousAnalyticalStructuredTechnical
Aspiring PM · Class of 2027 · Greater Noida
Start small, grow deliberatelyAbout Me (&)
About Me (&)
How I Got Here
I learn product management by doing the work: finding signals, making trade-offs, coordinating delivery, and reflecting on what actually changed.
'01234567890123456789
From data to decisions
Analysed marketing and web-traffic data, identified tracking issues, and translated findings into clearer business recommendations.
'01234567890123456789
Leading delivery
Coordinated 15+ real-estate client projects across technical, 3D rendering, and sales teams while keeping priorities, risks, and owners visible.
'01234567890123456789
Talking to supply first
Ran 45+ owner conversations before writing a single requirement, and let what I heard decide what BenNest would and would not ship.
NOW
Building product depth
Combining discovery, analytics, and technical prototyping to prepare for product management opportunities where outcomes matter more than output.
Selected workBuilt to Learn,
Built to Learn,
Made to Work
A focused selection showing how I move from problem framing to requirements, prototypes, validation, and delivery — and what each one actually taught me.
01
FastAPIAIDecision Systems
PI569 deterministic tests
02
DiscoveryNext.jsMarketplace
BN45+ owner conversations
03
AgileJiraStakeholders
CV15+ client projects
What
I Bring?
Capabilities overviewDiscovery ◍ analytics, and technical fluency ▚ combined — turning an ambiguous problem ◈ into a decision a team can actually act on ✦ this week.
Product Discovery
User interviews, market investigation, problem framing, journeys, assumptions, and MVP definition.
Data-Informed Decisions
SQL, Python, funnels, engagement trends, dashboards, and evidence-backed recommendations.
Delivery Coordination
Requirements, backlogs, Jira, sprint planning, stakeholder alignment, risks, and documentation.
Technical Prototyping
FastAPI, Next.js, APIs, databases, cloud architecture, Git, and functional validation.
How I workFrom Fuzzy
From Fuzzy
to Shipped
Same rigour at every size. The only difference is how much of the problem is already known when I start.
Discover
Weeks 1–2
Before scope, before tickets. Talk to the people living the problem and find out which parts of it are actually worth solving.
- User and stakeholder interviews
- Market and competitor investigation
- Assumption and risk mapping
- Problem statement everyone agrees on
For problems that are still fuzzy and need a shape before anyone commits.
Define
Weeks 2–4
Turn what I heard into something a team can build against: scoped, sequenced, and honest about what is being left out.
- Requirements and acceptance criteria
- Success metrics and instrumentation plan
- MVP cut with an explicit not-now list
- Prototype to pressure-test the flow
For teams that have signal but no shared definition of done.
Deliver
Ongoing
Keep priorities, owners, and risks visible until it ships — then read what the data says and feed it back into the next cut.
- Backlog grooming and sprint planning
- Cross-functional coordination in Jira
- Risk and dependency tracking
- Post-launch analytics and iteration
For delivery that has to survive contact with real clients and real deadlines.
Turn Your Idea
Into a Decision
Every product has a next step hiding behind an unanswered question. I am good at finding which question that is.
UT
Have something in mind?
Let's TalkPrinciplesWhat the Work
What the Work
Taught Me
Not theory. Five things I got wrong first, then corrected — each one tied to a project where it actually cost something.
Talk to supply before you build demand.
It is tempting to design the polished side of a marketplace first. The 45+ owner conversations behind BenNest changed the product more than any wireframe did — half the features I assumed were essential never made the cut.
BNBenNest45+ owner conversations
A tracking bug is a business problem.
Broken instrumentation does not show up as an error. It shows up as a confident decision made on numbers that were never real. Auditing what is measured is part of the analysis, not a chore before it.
GAAnalytics workMarketing & web traffic
Visible ownership beats a longer status update.
Across 15+ client projects spanning technical, 3D rendering, and sales teams, almost nothing was blocked by a lack of effort. It was blocked by nobody knowing whose turn it was. Naming the owner fixed more than escalating did.
CVConvrse Solutions15+ client projects
Prototype until the argument ends.
Debating an idea in a doc is cheap but slow. Building the thin version of it is slightly more expensive and settles the question. ProdIntel AI exists because a ranked recommendation was easier to judge than to describe.
PIProdIntel AI569 deterministic tests
Say what you decided not to do.
A requirements doc that only lists what is in scope is half a document. The not-now list is what stops a team from quietly rebuilding the thing you already ruled out three sprints ago.
PMWorking noteApplies everywhere
FAQGot any
Got any
questions?
Why product management?
Because the work I keep gravitating toward — framing the problem, talking to users, deciding what not to build, keeping delivery honest — turns out to be the job. The technical side makes me a better partner to engineers; it is not the part I want to optimise for.
Do you actually write code?
Yes, enough to be useful and not enough to be precious about it. FastAPI, Next.js, SQL, Python, Git. I prototype to settle arguments and to understand what I am asking engineers for — not to own the codebase.
What does your discovery process look like?
Interviews first, and with the side of the market that usually gets skipped. For BenNest that meant 45+ property owner conversations before any requirement was written. I map assumptions, mark the risky ones, and go test those.
How do you handle ambiguity?
Narrow it until a decision is possible. That usually means separating what we know from what we are assuming, picking the one assumption that would hurt most if wrong, and finding the cheapest way to check it this week.
What tools do you work in?
Jira for delivery, SQL and Python for analysis, GA-style web analytics for funnels and engagement, Figma for flows, and whatever the team already lives in. The tool matters far less than whether priorities and owners are visible in it.
How do you measure success?
By what changed for the user and the business, not by tickets closed. That means agreeing on the metric and the instrumentation before launch, so the post-launch conversation is about evidence rather than opinion.
Are you available for internships or PM roles?
Yes — I am class of 2027 and open to product internships, associate PM roles, and project work now. Fastest way to start is email; I will reply with context on what I have shipped and where I would fit.
What are you working on next?
Going deeper on product analytics and on AI-assisted decision systems — ProdIntel AI is where most of that thinking currently lives. Alongside that, more discovery reps, because that is the muscle that compounds.