I turn complex product work into clear decisions and working software.
I’ve led product work for enterprise platforms serving millions of users and built independent software from definition through launch. I connect strategy, requirements, design, and delivery so teams can make deliberate tradeoffs and keep the product’s purpose intact as they build.
I’m especially useful when the work spans teams, the goals are unclear, or the product has outgrown the way it is being managed.
You may be launching something new, replacing a legacy platform, or improving a product that already has a team behind it. The work needs clear priorities, a shared understanding of the problem, and someone accountable for connecting the decisions through delivery.
I work through goals, user needs, system dependencies, and business constraints with the people responsible for the product. Then I turn that understanding into decisions and buildable work: what matters, what can wait, what depends on what, and how we will know it works.
Email EmilyMy work spans ecommerce, healthcare, fintech, trade associations, and startups. It includes member portals, legacy-system migrations, integrations across payment and warehouse systems, and new products built from the beginning. That range helps me recognize where a product problem is really a process, ownership, or system problem.
Make the goals, requirements, constraints, and unresolved decisions explicit.
Give designers, engineers, and AI tools the context and boundaries they need to carry the product forward.
Review and test the work against the intended behavior before calling it complete.
Keep the product, decisions, and delivery plan aligned as the work changes.
Enterprise planning tools and independent products, with the problem, contribution, and decisions behind each.
01Map what you have before you decide what to build.
Built to get a room of stakeholders to agree on what a legacy platform actually did, before anyone tried to price the replacement. One HTML file, filled in by the team and approved in the meeting. It started as an internal tool — it’s for sale now.
Furniture, built-ins, and practical projects developed around real spaces and everyday use.
02Shelving designed around the room, its books, and an awkward radiator.
The build is progressing in stages.
Before anything gets built, I figure out what the product actually needs to do. That means the mechanics, edge cases, dependencies, constraints, and the decisions we’ve already made.
Confluence is the source of truth. If the implementation needs to change, the decision changes first. I don’t want to find out six weeks later that the code, tickets, and documentation all tell a different story.
I don’t throw vague tickets over the wall and hope engineering figures out what I meant.
Specs carry the context someone needs to build the right thing: what we’re building, why it matters, what rules can’t move, what it depends on, how we’ll know it works, and what needs a human decision before anyone keeps going.
The point isn’t to answer every possible question upfront. It’s to give the work enough structure that people and agents can move quickly without making up the product as they go.
I use AI throughout the development process, from planning and implementation through review and reconciliation.
Agents can do a lot on their own. They just don’t get to quietly change the product.
Shared schema changes, destructive actions, anything that costs money, unresolved product decisions, and anything that conflicts with the documented plan all require a stop and ask. I also flag legal, copy, design, data, product, and support dependencies early, because they’re cheap to solve before build and expensive to discover after.
The product-management loop is part of the development loop.
Jira moves when the work moves. A ticket goes from implementation to pull request to review to preview verification to release, and the PR leaves behind what changed, what was touched, and how to verify it.
Done means merged and verified. Not “the code is finished.”
Plans drift. Tickets get stale. Code changes. Documentation gets left behind. It happens.
So I built a reconciliation step into the process.
Specs, Jira, and the actual code get compared against each other. Work that shipped gets closed. Remaining scope gets rewritten. Missing work gets turned into tickets. And if the product changed, the plan and documentation change with it.
I want the board to describe the product that actually exists, not the product everyone vaguely remembers talking about three months ago.
The result is a closed loop:
I built this because AI made writing code dramatically faster. That changed where the hard parts are. More of the work now happens before and after the code: defining the right thing clearly enough to build, giving agents enough context to make good decisions, and checking that what shipped is still what we actually meant.
I’d rather do one useful thing well than sell you a retainer for a problem neither of us has named yet.
Product definition, prioritization, complex delivery, platform migrations, or a new product that needs experienced ownership.
I work best where I can contribute to product decisions and follow them through delivery. The engagement can be fractional, contract, or project based.
Remote by default and genuinely good at it. Madison if you’re local, and I’ll travel on expenses when being in the room matters.
Send the context, the goal, and the part that is proving difficult. You do not need to have the engagement figured out before we talk.