Finding where onboarding broke.

We’d changed who we sold to, and the product hadn’t caught up.

StackHawk started as a product developers found and set up on their own. By 2023 we were selling to enterprise security teams, and the market we wanted was API security. Parts of the product were built for one developer signing up alone, and it showed most in onboarding. Our onboarding numbers were slipping. Customers got their first few apps scanned, but fewer and fewer made it much past that.

Onboarding was heavy on people and process. Our customer success team spent a lot of time getting each customer set up and working through the hard technical parts with them. StackHawk was a very technical product. You needed technical skill to set it up, and you needed access to your own environment to put it there. Not every security team has that. So they jumped through hoops, it took a long time, and it was frustrating.

We had customer feedback on the product we already had, and new things we wanted to build. We needed to know where the new work fit, which problems to go after first, and how to turn all of it into a roadmap.

So in November 2023 we took two days to work it out together. Not a lot of companies can spare that much of a team’s time.

I based the workshop on Merissa Silk’s product vision canvas, from her article Canvas your way to product vision, which grew out of Roman Pichler’s product vision board. I rewrote it for a security product with two kinds of user and fit it into two days.

Day one was the canvas, ending on a first rough vision statement. We mapped the developer and the AppSec engineer separately, because by then they were two different customers.

Day two was the whole customer journey, from our website through rollout. The people closest to customers traced each persona’s real path across it in colored yarn, and showed us where people got stuck. Jeff Patton mentioned his crime board to me once, and it got me wondering if we could do something like it here. Then we sorted each problem. Was it the product, the docs, support, or onboarding?

Afterward my designers and I rebuilt everything in FigJam and I wrote the recap. We shared it around the business, and new work got checked against the wall before it went on the roadmap.

“

I’ve been through a lot of these exercises over the years at different companies, and this was by far the best run one I’ve ever been to.”

Matt Thompson, VP of Customer Success

Matt was new to StackHawk then. He said seeing our features next to how customers used them grounded his own onboarding, and showed him where to focus in his new role.

The workshop told us what to go after for the next year, some of it obvious and some of it not. The Q1 2024 plan put half of product development on the enterprise experience, cutting time to value and trial length, with research into the onboarding needs the workshop found. Another 20% went to research on the AppSec user and how to connect them with engineering.

I spent a lot of time with Matt on getting what customers told his team back to product and onto the roadmap. It took us a couple of years to get right. His team filed feature requests from a form in Slack, they landed in Jira, product managers triaged them every week, and we met with customer success on anything new to get the context before it went on the roadmap.

Our personas started out as product development personas, not buyer personas. The workshop let us define them and blend the two, so each one carried what product needed and what go-to-market needed. New employees learned who our customers were from them, sales used them to tell users from buyers and find the economic buyer, and go-to-market shaped its messaging and experiments around them.

In product and design, they changed how we built features. A very technical user wants configuration as code and an API, and will go write the code. A more traditional AppSec user who isn’t that technical needs more UI, more hints, and things made obvious in the app. The personas let us build for both.

On the wall, the security yarn got stuck right at the start, on “no context or guidance to help you start” and “where/how to get scanner.”

We shipped an onboarding dashboard as an MVP. Customers and the success team liked it, and we never went back to iterate on it. We made the scanner easier to find, download, and install. We rewrote the scan emails and the messages the scanner prints when it runs, updated the docs with clearer wording and screenshots, tried tours in the app, and started tracking what people did. We experimented with a lot, and not all of it worked. Very little of it ties back to one clean number.

The fix that did was years in the making. With a hosted scanner, you give us a URL and we run the scan, so there’s nothing to install and no config file to write. It shipped in September 2025 and brought in about $275K of new ARR in its first quarter, and proof-of-concept deals closed more often once a prospect could see results without pulling in an engineer.

After a few more rounds, our product designer rebuilt the whole path between January and March 2026. A security team fills in a form now instead of writing a config file, and signs in through a browser instead of setting up authentication by hand.