The First Week
I turned up to my first product internship expecting to argue about strategy. What I got in week one was a spreadsheet: ten thousand prospect records at Omniful.ai and a question nobody had written down properly. Which of these deserve a salesperson's time, and how would we know?
That spreadsheet was the whole job in miniature. A year later, across Omniful.ai, Wipro TOPS and now The Sleep Company, my honest summary is this. At intern level the job is not vision. It is reducing the distance between a decision and the evidence for it. Almost everything useful I learned was about shortening that distance.
1. A Metric Moves Because an Operation Changes
The Omniful number I put on my CV is that qualified prospects went from roughly 10 a day to over 200, and that the work was linked to 10 B2B acquisitions. What that line hides is the operational work underneath it.
Going from 10 to 200 was not a growth idea. It was a redesigned qualification workflow and a lead scoring model built on eight-plus firmographic and behavioural signals, plus 10,000 records structured into prioritised segments and weekly pipeline views the sales team would actually open. The hard part was agreeing what "qualified" meant so the same record got the same answer twice.
If you cannot describe the operation that produced a metric, you do not own the metric. You are quoting it.
2. The Demo Is Not the Decision
At Wipro TOPS I scoped Auriga ReX, an internal AI-powered enterprise workflow platform, defining the flow from transcript ingestion through AI extraction to governed document generation. AI products are seductive to demo. A good run in a meeting feels like proof, and it is not.
What actually moved work forward was duller. I defined and aligned Crew Mobile Microapp workflows across twelve-plus scheduling, assignment and compliance scenarios, and the specs are what moved that feature into active sprint development. On Non-Crew Records I wrote acceptance criteria, validation rules and edge cases, and surfaced three data integrity issues before development started rather than after.
Three issues caught early is not a headline. It is the difference between a sprint ticket and an incident.
3. On a Growth Team, the Funnel Is the Roadmap
I am on growth at The Sleep Company now, and the shape of the work surprised me. I expected campaigns. I got infrastructure.
Evaluating BSPs, CRMs, payment aggregators, OMS and WMS. Standardising the Shopify Master Catalogue and putting data quality controls around it. Mapping end-to-end PDP user flows. Building AI operational agents on a knowledge repository that did not exist before. None of that is a growth tactic in the LinkedIn sense. All of it is the funnel, because a catalogue with inconsistent data and a PDP with an unmapped flow are conversion problems wearing an operations costume.
The roadmap is not a separate artefact from the funnel. It is a claim about which part of the funnel you believe is broken.
4. Ship Your Own Thing and Your Tickets Get Better
Aarchid is an AI plant diagnosis product I co-built with Dilpreet Grover. I wrote the PRD, built the eval harness and shipped V1. It hits 92% accuracy on our 200-sample golden set and runs at the edge for under a quarter per active user per month.
Two things came out of that. First, the harness said 92% and the user interviews said trust was the real bottleneck, and holding both of those at once is a skill nobody teaches you in a framework. Second, once you have implemented your own ambiguous ticket, you stop writing them. Hackmate, a co-founder matchmaking platform that grew to 300-plus users organically, taught the same lesson from the other end: post-launch, the feedback loop is the product, and diagnosing where people dropped out mattered more than anything I had planned before launch.
5. The Portfolio Is a Product Too
This site has been through five iterations in three months, and each one existed because the previous one failed at something specific rather than because a new framework shipped. It is the only product where I am the PM, the engineer and the user research panel, which makes it an unusually honest teacher. I wrote about that separately in why PMs should code.
What I Got Wrong
I over-indexed on frameworks. RICE, JTBD, the full shelf. Frameworks are compression formats for judgement you already have, and I was using them as substitutes for judgement I did not have yet.
I wrote PRDs nobody read. Long, careful, complete documents. The specs that worked were the ones tied to a decision somebody needed to make that week.
Worst of all, I mistook activity for evidence. A busy week of interviews, dashboards and meetings feels like progress. It only is if something you believed at the start of it changed.
If You Are Starting Your First PM Internship
Ask what decision your work is supposed to inform, and ask it out loud on day one. Learn SQL properly, because waiting on someone else for numbers puts a queue between every question and its answer. Write down what would make you wrong before you go looking. Take the unglamorous ticket, since the person who owns the messy data model ends up owning the roadmap. And ship one thing of your own, end to end, so you know what your specs cost the people who implement them.
You do not need more opinions. You need a shorter path from what you believe to what you can show. Pick the loudest belief you are holding right now and go find the evidence, this week. Then start reading the eval harness instead of the demo.