Leader Spotlight: From Idea on Monday to Beta on Friday, with Emily Hottal
Emily Hottal is Director of Product at Airship, where she has spent more than 11 years building out the company’s product organization, moving from program and product manager roles into her current position leading product strategy. She sits on Airship’s cross-functional AI committee alongside legal, compliance, and security, and built an AI-powered product workflow using Claude designed to take a new idea from discovery through prototype, PRD, tech spec, and compliance review in a matter of hours rather than weeks. Hottal holds an MBA from the University of North Carolina at Chapel Hill and a B.A. in Economics from Drew University.
In this conversation, Emily talks about the AI-powered workflow she built for product managers and designers — one designed to compress the path from idea to prototype into a matter of hours, in service of a broader goal of moving from idea on Monday to beta on Friday. She discusses where the time savings really show up, why she deliberately kept parts of product discovery un-automated, how she won over an engineering team wary of “AI slop,” and what skills the next generation of product managers will need as AI reshapes the job.
Building an AI-powered product workflow
You’ve built out a product workflow designed to significantly reduce the time from ideation to development. Could you talk about that and share how teams are using it internally?
The product workflow is built using Claude. It uses a lot of skills. I used compound engineering to build out a workflow that product managers or designers, those were the people I was really thinking of when I built it, could use to speed along product development.
It’s a series of many different skills and it continues to be added upon. It has access to Confluence, to Google, to various different places where we keep our discovery notes from when we meet with customers and we take notes and snapshots of what we’ve learned. So it has all of this context readily available where a product manager doesn’t have to go and search for it, but they can also pull in their own notes and add to it if you’ve had some recent meetings and want to throw in those notes, it can take those and synthesize it with everything else.
For the first step, you pull in that discovery and then pull out what are the opportunities that I’m seeing around this. You can actually talk to Claude back and forth and brainstorm. What are the opportunities? What are the different solutions? It’s kind of having a partner to talk to and work through. Then from there it will hand off to the next skill when you’re ready to build out a product brief. So build out a PRD, and that PRD includes a lot of different elements that we don’t normally include as much for go-to-market and objection handling, things like that to prepare it for sales and really help them to understand what we’re going to be building out.
From there, you can have it build out the tech spec, build out the actual prototype and also then run it through a compliance and risk assessment, which will spit out a summary, create a Jira ticket and alert our legal team in Slack that this has happened so that they can quickly review the summary rather than having to go through everything, meet with a team. They get a summarized thing about what tools it’s using, if these tools have been approved in the past. The template to create that has been built by our legal team themselves to ensure they meet our AI governance requirements.
Where the time savings show up
I imagine there are huge savings associated with condensing the process so dramatically.
You can go through this process and if you kind of have an idea of what you want to do, I’d say a matter of hours, a half day. I think it’s best to go through and really think about it and take a little bit more time, but end to end, it’s very quick, and then legal’s on top of it — they don’t ever want to be a bottleneck. They do their review, it’s much faster for them.
This process can take weeks, months to build out. And while the prototype that we build isn’t something that is going to go into production, we don’t have that expectation right now. Hopefully we’ll iterate to get there and give more guidelines to make the prototype something that’s more production worthy. It’s something that helps to communicate to engineering so that they get a picture of what we’re really trying to build and all the different areas that it may affect much faster. So it really helps with the communication across the different teams, speeds that up.
There are so many groups that this workflow touches. Are the savings fairly equally distributed, or do you feel that some areas get a larger benefit?
I built this with product and design in mind, so I’m a little biased there. I’d say that the savings are really heavy on that side because something that takes a long time for a product is going out and talking to people, which we still have to do. You’re not going to replace that with AI. Go out, talk to people, get that direct feedback — what are their pain points, what are the opportunities, coming back with possible solutions and finding out their feedback on it.
We have years of input from them around different products, and going through and sifting through all of that — trying to find exactly what you need, what might influence what you’re solutioning, the different deal impediments, support tickets, things like that — takes forever to go through and you’re not going to capture it all. So that is a huge time savings with AI, being able to just instantly look through all of that and pull out what’s relevant to you. I’d say that is the biggest. And then writing out the product brief or the PRD, that’s really time-consuming.
This is so much faster. You still have to review it, make sure it’s exactly what you were thinking, what you were wanting, but it’s so much easier to make tweaks to it because it does a good job. It’s not total slop where you have to rewrite it. It’s doing a nice job. It’s really just working through it like you would maybe a more junior coworker and trying to convey exactly what you’re doing, and then getting that prototype to really help you explain it to engineering and pull them in and get that common understanding.
We have a lot of different interactions in Airship — I’m sure many other platforms can relate. You may be building one product or feature in one area, but it ends up that it touches all these other areas that you may not think of right away, and sometimes our docs team catches it, sometimes engineering catches it. So it really helps to find those faster.
Fine-tuning the tool as a team
As you go through the initial few iterations of creating and reviewing a PRD, are you able to train the tool to get even a little bit closer to where you’d want it?
The way we’re doing that is actually more of a group effort. The PRD that spits out isn’t exactly our template that we use for product reach — it’s missing some areas. Another coworker has built out a skill to address that, make sure that we’re getting all the areas. I’d say it’s a group effort to fine-tune this and get everything you need. Something I missed in the first iteration of this workflow was the ship-it we send — what we call a ship-it. When we release a product, we send an email notification to everybody in the company, letting them know about what it is and all the details, how to use it, why we build it, and thanking the team and things like that. Another coworker added that to this product workflow as well. So there’s a lot of fine-tuning going on as people use it, and it’s in GitHub, so everybody can make changes to it and we can all pull down the latest and continue to refine it and make it better.
Can you say more about how the template helps the teams move faster without creating more unnecessary risk?
We have a legal team member who came up with the template. He’s been leading our AI governance requirements, so he’s very familiar about what needs to be included, how it needs to be included. We need to make sure that legal’s alerted and understands what the product is, and it runs through that compliance and risk assessment so that they can evaluate it. But they also need to be able to track the product and understand where it is in the process so that they don’t become the bottleneck, and they also know if it’s actually moved into beta. So that’s where he said, we need a Jira ticket to track this that we’re alerted to so we can follow it. And that’s linked to the compliance and risk assessment so that they can see that and reference it at any point. And then we have that tracking history that we need for AI governance requirements as well. So a huge benefit of getting legal involved in the process is that product risks get surfaced early and often and can be accounted for through development, and we avoid the situation of Legal coming in at the 11th hour and pumping the brakes on a release.
What AI still can’t do
Were there any parts of the process that you chose not to automate that you intentionally excluded?
Going back to the discovery, you can’t automate talking to a customer directly. You can automate pulling in the notes — we record our calls, and we pull in those notes and it’s able to pull from that — but I purposely made that discovery and brainstorming portion more of a, it needs to be a conversation. You need to ask questions. Don’t just go and do it. The product manager needs to be involved. It needs to have that person, have a lot of their presence and thinking in there.
Getting engineering on board
When this was first launched, was it difficult to get engineering on board? Were they hesitant that they might be receiving AI slop, or that they wouldn’t be brought in early enough to the process?
I still like to bring them in early, bounce off ideas. They always need to be included. They’ve got their own thoughts, and we work in a trio — design, engineering and product — so we still always talk. But when I initially built this, I went in a little hard. I was a little excited. I’d seen what you could build out, and there were some on engineering who were supportive. They were like, “Yeah, seems like a good idea. You could do that and could probably get into beta.” But then there were others that raised concern, and engineering was like, “Oh yeah, you’re right. That’s maybe not the best.” So what came back was, “We don’t want to be QA for AI slop,” which I totally understand — we don’t want to be putting things into production that are not great.
I worked with an engineer and had built something out using, at the time, using Cursor, and he took a look at it, and he thought it might take as much time to refactor this and fix a few things as it would for me to write from scratch. Writing the code is not the slower part. The slower part is usually understanding what you actually want to be built. And what he found was this was very useful for him to really fully understand what I was trying to convey in a product brief and what I actually wanted to be built — all those little areas that you might not think of when you’re building out a product, all those gaps and questions that would come up as they’re trying to build it. That’s what really slows things down.
He did find a lot of use in this, as did the rest of engineering, as long as we framed it as no expectation that what we put out with AI is going into production. It’s more of using it to convey things to engineering, and now we can build guides along to get it better and better and improve it — but for now, let’s have that expectation that it’s more of conveying an idea. That’s been really helpful, and that’s gotten buy-in from engineering to work with.
Certainly the main goal of this project was to accelerate the path from idea to execution. What has become harder as you’re moving so quickly?
It’s been a big adjustment on how we leverage all this to be faster ourselves and make better use of our time. When all this came out, when I was building out the product workflow, there was a lot of excitement throughout Airship. I think across all companies, Claude Code got really big, really good, and everybody started building out workflows, and it just felt like this crazy period of a month or two where everybody was discovering this new power. It felt very frantic and hard to focus, because I was doing my thing and somebody else is doing theirs and pinging me about, why can’t we do this, why don’t we do this. It was very hard to focus. I think that’s going to continue to happen as AI evolves — people get excited, and then it’s just, how do we apply this? Now things have kind of calmed down a little bit for now, and we need to get a process in place and how to implement it into the day-to-day.
We work in trios — product, engineering, design. We go out, we talk to customers, and in the past we’d come back, we’d meet, we’d talk about what we heard, and then we’d build out an opportunity map, and then come up with solutions and start to talk about what those solutions are, wireframe. It was a very slow process, and we want to continue to work in those trios. So how do we implement this in a way where we can actually move a lot faster but still together?
That’s something we’re kind of experimenting with. We have a designer who’s working with a couple different teams to try and do it and then scale it across other teams. So everybody’s kind of experimenting in their own way as to how we actually start to implement this and move forward faster. So our goal is really to go from idea on Monday to beta on Friday, and that’s what we’re really working towards.
The new PM skill set
We talked about the goal of going from idea to prototype, a Monday-through-Friday type thing, which is incredible. Are there other metrics or signals you look at to measure the success of the workflow?
It’s still really early in the process, but right now I’m looking at the adoption — talking to team members, seeing what they’re adopting, if they’re adopting it, and seeing how much is being added to it by other team members. Like I said, we have someone adding the ship-it, adding more context, a product brief. Something we did to test it out, which I thought worked really well, was testing out the AI governance process. We took the template and we took an older product brief of something that they had manually reviewed and ran it through the skills for the compliance and risk assessment to see what the outcome was and make sure that it matched what legal wanted to see from it and what their expectations were. It’s still early yet to tell you what metrics or signals.
Looking at the newer generation of PMs coming into the craft, are certain skills more useful or more sought after now?
Definitely. And I think that those skills, unfortunately, are a little harder to evaluate than maybe the skills that were important before. Now I’d say the things that are more valuable are strategic thinking — really understanding what’s necessary, what’s needed, what the customer really is looking for, having a real deep understanding of that, not just what AI is telling you, being innovative, having that vision of where things are going, not just with what you’re working on, but the product as a whole and everything else around it, because everything is shifting. People are building out these workflows all over in different areas, and that’s going to then affect your product. So really understanding a very large scope of vision and having good judgment.
With AI, you use it to build out these PRDs, to strategize and things like that, but you really need to understand it yourself too. If you see LinkedIn posts, you can tell a lot of those are coming from AI because they all sound the same. You don’t want your product that you’re building out to be the same as everyone else’s because you’re just throwing in a prompt and doing what AI tells you. You really need to have a deep understanding of the landscape and what customers want so that you don’t just listen to the AI and do what everybody else is doing.
Adaptability — things are moving really fast, and you need to as well. If you’re still doing that process I described before, that’s so slow and so long, you’re going to be left behind. You’re not going to be able to innovate and build out your product fast enough. It’s really critical that you start learning how to use AI tools and how to use them really efficiently — not just plopping in something, getting the AI response, and using that, but really exploring and getting the most out of the AI tools so you can use them more as an assistant. And then adjusting your own process to match the changing times, seeing how others are too, so you can get ahead of your product and where it’s evolving.
And then the last thing I’d say that’s super important still is the collaboration — having trust, building trust, having influence, having an analytical mindset to really help people understand where the product’s going, making those right bets so that they do trust you. Working with people, building those relationships, it’s not going to change. That’s always going to be important. That’s not something that AI is going to change. As far as the less important — the writing, it’s so much easier now to have an AI assistant just write things out for you, build a prototype to help you communicate your thoughts. That whole communication is getting easier, but you still need the relationship building.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.