If you’ve got product work nobody owns, I want it.
I’ve built products for millions of users at large companies, and alone on the weekend on my own. Doing both is how you learn what a compromise costs, so I’d rather you compromise on purpose than by accident.
You have product work that nobody owns.
Maybe there’s no product person at all and it’s landing on you between everything else. Maybe there’s a team with a hole in the middle of it. Maybe the thing shipped a year ago and nobody has decided what it’s for since.
From the inside it looks the same either way. Decisions get deferred because nobody has clear authority to make them. The roadmap turns into a list of everyone’s requests. Engineers keep building and nobody can say whether it’s the right thing. The work that would fix it needs someone senior, and it doesn’t need someone full-time.
Work gets stuck in ordinary ways. Everyone in the room has a slightly different version of what you’re building and everyone thinks they agree. Two teams solve the same problem without knowing about each other. A decision made in one place breaks something in another and nobody notices for a quarter.
None of that is anyone’s fault. It’s what happens when enough people are working on something at once and nobody is holding all of it at the same time.
That’s the messy middle, and it’s where I’m most useful. I think in the whole picture. I can see how the pieces connect and where two of them are about to collide, and I can take something complicated and make sense of it for everyone else. That’s usually how people end up agreeing.
Email EmilyCompanies from 100 to 60,000 people. Ecommerce, health tech, fintech, trade associations, startups, and a few that don’t fit a category.
I’ve built ecommerce running in dozens of languages, wired into payment and warehouse systems that were never designed to speak to each other. Member portals where millions of people depend on a thing arriving correctly and you don’t get to be clever about it. New products where nothing exists yet and nobody has decided what it should be.
All of it breaks differently. Retail breaks at the seams between systems. Healthcare breaks at compliance and legacy. Startups break because there’s nothing to push against yet. That’s what a lot of different rooms gets you. I recognize the shape of a problem faster than I could from inside any one of them.
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.
Eleven products, and all of them started as something I needed.
01Talk to a verified trade pro before you touch the wall. Flat price, no service call.
Came from remodeling our own house, where I had one extremely specific question, then a hundred more, and nowhere to ask any of them. I ended up emailing the drywall doctor on YouTube because I couldn’t find a video.
Off the clock, the same brain cuts the joinery.
02Floor-to-ceiling shelving, designed around the books and the one awkward radiator.
Designed around what was actually in the room instead of what a plan assumed. I just finished the second of three banks of shelves in my kid’s room, one business year after the first. The third should take another three to five.
I’d rather do one useful thing well than sell you a retainer for a problem neither of us has named yet.
You know something needs to happen and you can’t put words to it yet. Naming it is the first thing I’d do anyway.
You’re about to spend real money building something and nobody’s certain it’s the right thing.
The roadmap is a list of everyone’s requests and nobody can say what’s actually next.
Something has been almost done for a quarter… or more. I won’t judge, this is a safe space.
You need one person who can go from what are we even doing here to a working thing.
You already know exactly what to build and you need hands. I’d ask a lot of questions about things you’ve already settled, and everyone would be annoyed.
You want the work administered rather than owned. Someone more junior will do it better, and cheaper.
Tell me what’s going on and we’ll scope it together.
Project based, fractional, or something in between. We’ll find the shape that works.
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.
You do not need to have the engagement figured out. Send me the messy version and I’ll tell you where I think I can help.