mabl · Product strategy
Shaping mabl for agent-driven software development
I help lead mabl's evolution from traditional test automation toward a product built for a world where more software is created and changed by agents.
The problem
Coding agents now write and change a large share of software. Teams ship faster. Review and testing have become the slow step. Most test automation was built for a person clicking through an app in a browser. mabl needed to show up where agents and developers already work.
What I did
- I mapped the agentic development lifecycle and where testing fits in it. I turned that into a customer-facing research piece that describes the workflow without pitching the product.
- I built a working prototype of mabl at the pull request. A coding agent opens a pull request. mabl finds the tests that matter, runs them against a preview environment, and reports results back on the pull request.
- I designed the direction for mabl's in-app chat. I decided the app is not the main interface. The main interface is the coding agent, the command line, and the pull request. The app's job is to stay simple and clear while usage moves to those places.
- I checked every capability claim against what the product actually does today. I wrote down what is still missing. mabl cannot yet pick which tests to run for a given change. It cannot yet scan a whole suite for behavior no test covers. It does not yet record who approved a test plan.
- I wrote the design brief for a live demo on real software, timed against a real demo slot.
What I learned
- A working prototype finds gaps that a slide hides. Building it early changed the plan.
- Engineering audiences check every claim. I keep a written list of what ships today and what does not.
- Choose one primary surface. The other surfaces support it.
- Time the demo end to end before the day. Our first full run was longer than the slot allowed.