Frontend Dev.
Product Manager. Emergency Designer.

I didn't plan to become a product manager. Nobody does, really — at least not on a three-person dev team where "product manager" isn't a job title anyone holds. You become one because the product needs someone to, and you're the person who understands it best.

When I started on SAUT, I was a frontend developer. 100% coding, 0% opinions about feature prioritisation. Four years later, I was spending 40% of my time on product decisions, 30% coding, and 20% designing screens. The shift wasn't a promotion or a role change — it was the natural consequence of building every screen in a product for four years straight.

Phase one: just build

V1 was straightforward. Tropics — the design studio led by Zubin — handed us Figma files. I turned them into Vue.js components. The spec came from the product documentation, the designs came from Tropics, and my job was to make them real. Student profiles, IEP creation flows, assessment interfaces, the curriculum browser — I built them all, but I didn't decide what went into them.

V2 was the same, initially. The first half of the rewrite was pure execution: migrate the frontend from Vue to SvelteKit, rebuild every component, every layout, every interaction. The timeline was five months. There was no room for product thinking — there was barely room for lunch. You ship what's specced, you ship it fast, you make it work.

Phase two: the shift

After V2 went live, the pressure changed shape. The core system was stable. Teachers were using it. The urgent work shifted from "build the thing" to "decide what to build next." And that's where the role started to blur.

We had a 65-feature roadmap phased across six releases. Someone had to decide what went into Phase 2.1 versus 2.2. Someone had to balance what the client wanted, what the teachers needed, and what the three-person team could actually deliver. Someone had to get on the daily call and say "this is what we're doing this week, and here's why."

That someone was me. Not because I had PM experience — I didn't. Because I'd built every screen in the system. I knew the data model inside out. I knew which features were technically cheap and which ones would take two sprints. I knew what the teachers actually used versus what the spec said they'd use, because I'd watched them use it during UAT sessions.

Product decisions

Product management on a small team isn't strategy decks and OKRs. It's daily triage. The client wants feature X by September. The teachers are struggling with feature Y that shipped last week. The backend engineer says feature Z needs a database migration that'll take three days. And you have one sprint to figure out the right order.

The advantage I had was that I could evaluate every request through the lens of someone who'd build it. "Can we add offline support for case studies?" I didn't need to ask engineering — I was engineering. I knew the service worker already handled attendance and daily assessments, and extending it to case studies would mean syncing more complex state. I could say "yes, but it's a Phase 2.3 item because of the sync complexity" in the same call where the request was made.

That speed — collapsing the feedback loop between "what should we build" and "what can we build" — is what made a three-person team ship sixty-five features. There was no handoff delay. No "let me check with the dev team." The dev team was in the call, making the decision.

Emergency design

Tropics — the design studio — handled the visual design. They set the design language, built the component library in Figma, and designed the core screens. But a 65-feature roadmap across six releases generates more screens than any external design team can keep pace with, especially when the dev team is shipping weekly.

So when a new feature needed a screen and Tropics was heads-down on something else, I designed it. Not from scratch — from the existing design system. I knew the spacing scale, the colour tokens, the component patterns, the interaction conventions. I'd been implementing them for years. Designing a new screen meant composing from the established vocabulary, not inventing a new one.

The classgroups interface, parts of the reporting dashboard, several of the admin screens — those came from me, not Tropics. I'd sketch in Figma based on the existing patterns, discuss with the team, and then build it. The advantage was zero translation loss: the person who designed it was the person who coded it. No misinterpreted padding. No "this component doesn't exist yet" surprises.

What each hat taught the others

The thing about wearing three hats isn't that you become three separate practitioners. It's that each discipline informs the others in ways you don't expect.

Engineering informed PM: When you've built every feature yourself, you have an intuitive sense of cost. Not in story points or sprint velocity — in real terms. "This feature touches three database tables and two service worker sync paths. That's a week, minimum." Product decisions grounded in engineering reality ship faster because they don't get sent back.

PM informed design: Understanding what the teachers actually needed — from daily calls, from UAT sessions, from watching them struggle with specific flows — meant the screens I designed solved real problems. Not "what would look good in a portfolio" but "what would make this teacher's 3pm assessment routine take two minutes instead of ten."

Design informed engineering: Designing a screen before coding it forces you to think about the user flow before the data flow. Which state needs to be visible? What happens on error? What does "loading" look like when the connection drops? These questions surface in design that would otherwise become afterthoughts in code.

The 65-feature roadmap

Managing a roadmap sounds abstract until you're the one deciding what ships this month and what waits. Phase 2.0 was non-negotiable — the core had to work before anything else. But after that, every phase was a negotiation between what the client prioritised, what the teachers needed most urgently, and what the team could deliver without burning out.

Reports got pushed to Phase 2.4 because the data infrastructure wasn't ready in 2.2. Case studies moved up to 2.2 because teachers were filing them on paper and losing track. The digital curriculum — individual parent subscriptions — went last because it was a new business model, not a fix for an existing pain point. Every phasing decision had a reason, and most of those reasons came from watching teachers use the product.

All six phases shipped. Every feature made it to production. That's the number I keep coming back to. Not the technology, not the framework migration, not the bilingual support. Sixty-five features planned, sixty-five features delivered. With three developers and no QA team.

What I'd tell myself

• Don't wait for someone to give you the PM title. If you understand the product better than anyone else in the room, you're already doing the job — you just haven't named it yet.
• The best design work I did came from constraints, not inspiration. Designing within an existing system — same spacing, same components, same patterns — is harder and more valuable than designing from a blank canvas.
• Small teams win when the feedback loop is tight. Daily calls, same-day decisions, ship-on-Friday culture. The moment you add a handoff step, you lose a day. Multiply that by sixty-five features and you lose months.
• Building the same product for four years teaches you things that jumping between projects never will. You see the consequences of your early decisions. You live with the shortcuts. You learn that the component you built in a hurry is the one you'll be maintaining for the next three years.