Podia’s product process

This article is inspired by a tweet I made back on July 16th. Gregg Blanchard on Twitter asked if I could turn the tweet into a post and elaborate more on each stage of our process at Podia, so that's what I've done. Thanks for the inspiration, Gregg!

Yearly roadmap

Between Christmas and New Years, I take a little downtime, but I also spend it writing up a Yearly Product Roadmap for Podia to present to the team during the first week back.

Every Yearly Product Roadmap starts with a brief history of what we did during that year. For us, it goes all the way back to 2014.

After the brief history (which only gets one additional line every year, but does provide context as to where we came from), I write out a reflection on the product work from the previous year.

While every year has a loose theme, I always cover the same topics: whether or not we hit our goals, if the goals shifted throughout the year because we learned new things, and what, if anything, we thought we were going to do, but didn't.

Then I write a bit about our KPIs and how well we performed for the year and wrap it up with a few FAQs.

After concluding the review of the past year, I start to write about what we want to do for the next year. As I mentioned above, every year has a loose theme, which is usually tied back to the major product ideas that we want to work on for the upcoming year.

After writing about the theme and the major product ideas, I write out the high-level new features and current product improvements that we want to do in a table and bucket them into themes.

From there, I take every high level feature and break it down one or two layers deeper to give more context as to how we might address it.

Lastly, I'll assign a specific “to do” to each developer and designer for them to focus on at the start of the year.

Quarterly roadmap

I don't create a Q1 Roadmap, because we just start by working off the Yearly Product Roadmap.

By Q2, we've learned more in Q1 than I knew back in December when planning for the year, so the Q2 Roadmap will have new things on it and some old things will be removed.

These Quarterly Roadmaps start off by reviewing the previous quarter by outlining what we released, what's in progress, and what we still want to do or not do.

From there, every feature is listed out with a few paragraphs on each with a high-level overview; the goal here is to give context around why we're building each one.

Accompanying the list of features is a table that shows the “Status” for every feature for the quarter, links to the specs, links to Trello, links to Figma, and who is working on it.

Some of the features in the table won't have anything listed out until it's time to start those features.

We don't write the specs until a few days or a week before we're going to start on a new feature because we want it to be fresh; we don't write specs for features we never build because what's the point in that?

Strategy doc

The strategy doc is short, concise, and it outlines the feature that we're planning to build. I write these to have a lot of context as to what we're building and why, what I think it should be, some example screenshots of where it could go, and what's unknown/still needs to be figured out.

These aren't supposed to include the entire spec, because for that, I want to spend time with a designer and/or developer to work it out exactly.

Specs collaboration with me/designer/dev

Once the strategy doc is done, and the time is right, I'll jump on a video call with a developer or designer to discuss the spec. We'll go over the strategy doc and talk about the specifics as to how we might implement this.


If we need designs, the designer will go off and start designing it; we use Figma. Once there's a design to review, we'll start leaving comments and talking through everything in Figma.

Somewhere in the design process, we'll loop in a developer to review the designs to make sure we're all on the same page in terms of how this will get implemented.

If the screens require copy, we'll loop in our copywriter to write it.


Once the developers start working on the code, they’ll keep me and the designers up-to-date on their progress in Trello and Slack. If during that process they get stuck or if they have a concern as to how something was designed, they'll voice that.

Dev/design clean up

We'll then make any changes we need to make after we see how the feature is working on our staging servers.

Most of the time, we don't really have many changes to make on staging as we've been collaborating throughout the process.

Deploy feature flag

We'll then deploy the feature to product behind a feature flag where only we as the Podia Team can see it. If it's something critical like touching the checkout process, we'll let it run for 24 hours or so before removing the feature flag.

Write announcement / write help doc

While the feature is deployed behind a feature flag, I'll write the announcement and the developer who worked on the feature will write the help doc.

Once both are drafted, our copywriter will review both and make any necessary changes before going live.

Remove feature flag

Next, we remove the flag so that everyone has access. We’ll wait an hour or so to make sure everything is working okay.

Announce 🙌

Send the announcement!

We'll either opt for an email to all of our customers (on paid accounts and people on trial accounts) or we'll just send an in-app notification; the kind of notification really depends on how important the update is to our customers.


Once the feature is live, we'll gather up the feedback we got from customers and post them into our #product channel in Slack and review any data we're tracking in Metabase about how the feature is performing.

That's it. I hope you find this helpful and please let me know if any questions in the comments. 🙌


comments powered by Disqus