Krista Rose King
Most of what I know about a product comes from listening closely to end users, lightly but persistently pestering smart coworkers with questions, and getting close enough to the work to break it myself.
I like hard problems, but I care just as much about the people solving them with me. I try to be useful when someone is stuck, thoughtful when a decision has real weight, and persistent about fixing recurring problems so the team can spend its energy on better things.
A couple quick brags
I help lead mabl’s shift from traditional test automation toward workflows built around coding agents. A lot of the work is figuring out where testing belongs when software is being created and changed somewhere other than the product UI.
Read case study →I led mobile testing from early customer discovery through product definition, design, pricing inputs, launch planning, and release. It grew to roughly $1M in revenue in its first year.
Read case study →As engineering started shipping faster, the PM team did not magically get more hours. I built connected automations to keep customer issues prioritized, pull scattered feedback into backlog decisions, and make sure customer-facing teams knew what actually shipped.
Read case study →Little nuggets from the noggin
Three conversations that changed how I think about product judgment when the technology underneath the work keeps moving.
Read this one →The agent vocabulary I’ve picked up over the past year, explained in the plainest language I can manage.
Read this one →Agents are much more useful when they can finish a task without stopping every few minutes. The tricky part is deciding which actions a team is comfortable handing over.
Read the excerpt →Coding agents can make changes quickly. Teams still need a separate way to check that the change actually worked and did what the developer intended.
Read the excerpt →When assumptions keep changing, a roadmap gets stale fast. I’ve been thinking about which parts of a plan should stay steady and which ones should be easy to change.
Read the excerpt →More capable software gives people more ways to get confused when something goes wrong. Clear states, sensible defaults, and easy recovery still matter.
Read the excerpt →Changing an established product means carrying current customers with you while the new model takes shape. Most of the hard part is in the sequencing.
Read the excerpt →About
I started in civil engineering, moved through UX and quality engineering, and eventually landed in product. That path made me pretty systems-oriented: I like understanding how things work, finding the real problem underneath the obvious one, and working closely with technical teams.
Currently I’m at mabl, working on software quality, developer workflows, and what changes as more software gets built by agents. I care about good product judgment, strong engineering partnerships, and useful products without a lot of jargon.