Veronica Melin, Product Operations

november 2025

process redesign

release process

13 statuses, simplified into 6. The bottleneck risk never materialized.

problem

Product and engineering were attempting to follow a consultant-created process. It seemed reasonable on paper, but was too heavy and complex to follow in practice. Meanwhile engineering's output was climbing fast enough to matter: AI-assisted engineering was significantly increasing velocity on flat headcount, and a product team buried in overhead was going to become the bottleneck holding engineers back.

findings

We had 13 statuses documented. Only 6 of these statuses were regularly used.
We were asking Product Managers (PMs) to track a large number of fields for all features, regardless of the size.
The process was documented well in Confluence, but almost no one could tell you where the documentation lived, let alone find what they were looking for.

13 → 6statuses

every stage cut to what people actually used: discovery, development, releasing.

solution

In partnership with engineering leadership, I kept the process shape and cut the granular statuses, unused fields, and other low value administrative tasks.

New requirements separated work into three segments based on size. Large effort items had more documentation requirements than the small ones. Smaller items were able to flow through the system with minimum hand holding, freeing PMs up to focus on the larger, more strategic work.

I took the documentation to the basics and built a chatbot on top of it. This allowed PMs to get a quick sense of next steps if they were unsure.

Most importantly, I stressed freedom in a framework. PMs had the autonomy needed to bend the rules based on the needs of an individual feature.

small work flows through light; big bets get the full picture.

outcome

Before the change, there was real concern that engineering would start outpacing the backlog, the exact bottleneck the process redesign was meant to prevent. With the simplification in place, that risk never played out, even as AI-assisted engineering kept increasing output.

march 2026

process redesign

launch process

70-80% faster beta-to-release time.

problem

The process of taking a large, strategic feature from beta to fully released took about 3-6 months after engineering signoff, significantly delaying time to value for our customers.

Everyone kept referencing "the handoff" between product and the go-to-market team like it was one moment. I went to find out when that actually was.

I was told we needed to ship faster. I sat down with all the stakeholders involved to map out what each of them actually needed from product, and when. Then I modeled what it would look like if everyone got everything they asked for. The answer was a mess.

findings

A lot of what people were waiting on wouldn't happen without someone proactively asking "hey, what's going on with X"
Other asks didn't need any cross-team dependency at all, they just needed someone to actually do them
Some requested information was stale by the time anyone needed it, or already discoverable elsewhere, so teams were redoing work that didn't need to happen
Marketing tracked their side of launches in a separate project management tool, so there was no shared place across teams to see where anything actually stood
Product marketing had already documented needs that scaled with launch tier, but the business wasn't following them, consistently asking for extra work on smaller launches

solution

I built and implemented my "Zipper System," where instead of picturing a baton handoff between departments, we began to think about the company as a zipper with deliverables on each side, clearly defined when and where it fits. Instead of one big handoff, each individual cross-functional point was identified, defined, and automated with Slack reminders, so nobody had to remember to trigger it.
The Product Marketing Manager (PMM) and I got two execs aligned on the proposal who historically don't agree
Created a dashboard based on source data, showing the business exactly what they needed, when they needed it. This eliminated the need for product managers to update a launch spreadsheet of information.
Sold the business on trading hand-fed information for self-serve access to it any time, so what they actually asked for went down
Built PMs a guided system, scoped by launch tier and effort size, that surfaced exactly what was needed and when as they worked, so small launches carried only the bare minimum while the biggest ones got full effort. The system was integrated with our data source, so they could update information where they were most comfortable.

the old process: one long staircase of sequential, one-off handoffs

the zipper system: handoffs defined at each point, not one big baton pass

outcome

We turned a fixed 3-6 month beta process into a far more flexible 4-6 week one. With clearly defined roles, deliverables, and expectations, several major launches went through it without slowing down smaller releases.

may 2026

self built

internal product app

73% week over week stickiness. Adopted before formal launch.

problem

It grew out of the launch process work. First, a dashboard for Product Managers (PMs): what a feature still needed, synced to Productboard, scored by how complete each PM's launch prep was. Then a broader view for everyone else who needed to track launch readiness (enablement, product marketing, Customer Success (CS) leadership): a breakdown of what was releasing, when, and whether it was still in preview. Product and engineering already had that visibility. Nobody else did, and Productboard couldn't produce it directly.

Then the CS team started striking out in Productboard too. The tool was built for the product team, and it did that job well. It just wasn't built to hand someone outside product an answer in a format they could actually use. When logging feedback isn't your job, and doing it is hard, you stop doing it.

The bigger problem ran underneath: nothing talked to anything else. Confluence, Guru, Slack, GitHub, Jira, Productboard, Loom, Google Suite. Pick a question, and the answer lived somewhere else. Neither the product team nor the rest of the business could reliably find anything.

solution

I couldn't change the layout or access model of tools we'd already bought, and I couldn't change who had access to which system. Getting engineering time to build something like this was never going to happen, and making that case alone would have taken time I didn't have. What I could control was solving the problem myself.

The first two tools lived in a low-code platform with an AI chat interface, built to solve each problem as it came up. It got the PM dashboard and the launch-readiness view running fast, but the interface was limited: it couldn't run my own code, so there was a ceiling on what either one could actually do. When CS needed something too, I migrated everything to my own app instead of bolting a third tool onto a platform I'd already outgrown, which gave me room to consolidate all three into one place and pull in Salesforce data for reports neither that platform nor Productboard could produce on their own.

I started narrow. Reports built around each CS rep's own book of business: every account, every request grouped underneath it, where each sat in the pipeline, and what had recently shipped for them. Something to open before a client call instead of guessing.

Then I went further: a dashboard that mapped exactly what information a feature needed before it could ship. Small, medium, and large features carry different release requirements, and marketing tier changes how much ceremony a launch gets. It syncs both ways: a PM can work from Claude Code, Productboard, or my application, and the update shows up in all three, so nobody has to remember to log the same thing twice.

Under the hood, I kept building as the tool grew past its first version:

Usage analytics and role-based user permissions
An integrations UI over my own integrations, so connections could be managed without touching code
A testing suite, plus several API migrations and deprecations as the underlying platforms changed under me
Data joins across Salesforce, Productboard, and my own database, so a rep or PM sees one merged view instead of three

stickiness score

roadmap coverage

active integrations

cumulative visits over time

usage analytics: one view instead of three tools

a kano delighter

The Kano model splits requirements into basics, performance, and delighters: the stuff nobody asks for but remembers. I borrowed Claude Code's habit of narrating itself while it thinks ("Noodling…", "Scheming…") and wrote company-specific versions with a few easter eggs scattered through the app: a longer load might say "fetching your data… (eventually)."

PM-specific pages show: “wrangling Veronica’s brain…”

More than one person reached out, unprompted, just to say it made waiting for a screen to load fun.

▼ Q1

▼ January

▼ Feature Detail 1/22/2027

Problem:

Cause:

Solution:

Use Cases:

Owned by:

Enablement Deck:

Technical Documentation:

Clients requesting:

▶ Feature Detail 1/28/2027

▶ February

▶ Q2

the roadmap view: every field a feature needs, gated by stage

outcome

A production tool the product org, CS, and the wider go-to-market side of the business now run on day to day. Role-based permissions, usage analytics, and the company's complete roadmap in one place, no Productboard login required. I asked the CS team to try it and tell me what was missing, and before I'd launched anything formally, the usage analytics were already showing people coming back and which pages actually held their attention. Adoption grew organically, by word of mouth. The underlying database is still being built out, but the analytics, permissions, and integrations already stand on real infrastructure, not one-off scripts.

73%week over week stickiness

One Zylothe application's success led to a company values award

ongoing

personal project

garmin dashboard

problem

Garmin has years of my data, but there's no way to customize the reporting. Some views showed a rolling 30 days, others a year, and past that I had no idea what existed or where it went. I wanted to see how a hike in Colorado's altitude actually stacked up against the same effort back in flat, low-elevation Indiana, where I grew up, and whether any of it was doing something for my health.

Some of this was never really a problem. I just thought it would be cool: watching a map fill in as I finished more local trails, picking out a few absurd milestones, an Everest's worth of cumulative elevation, the distance an Arctic tern flies in a single year, just to see how close I was getting.

solution

I set up an app to see my Garmin data in the way that I want to. I can see how different health metrics correlate, how I'm doing year over year, and how much of the state I've covered on foot.

Nobody else would want this app in its current form. I use it every week.

everest · ✓ summited 2x · 37% to #3 237% 68,684 ft this year

denver to the pacific 47.8% ~526 mi this year

stress vs. sleep, and every trail mapped as I hike it