From Pitch Deck to Product
The story of helping a B2B SaaS founder crystalize the product vision, design a differentiated MVP, and go to market.
Case Study
This case study aims to share my design process by answering the question: how do you go from a loosely formed concept or design problem to an easy-to-use product that converts?
The Challenge
Chris Paterno was a first-time founder with a great idea and expertise in advertising and marketing for Record Labels. Having run an ad agency for 2 years, Paterno learned that music marketing and advertising could be automated. He hired me to help him turn his pitch deck and rough wireframes into a simple and useful B2B product that could be sold to record labels.
My Role
I was hired as a consulting product designer and joined full-time as the first product manager to manage the 8-person remote development team.
“I hired Stevie to bring our product to life. He fought in the trenches with me to help us find our brand and crystalize our vision. He made our difficult challenge fun to work on thanks to his unmatched dedication and passion.”
- Chris Paterno, Founder & CEO at Disclosed Music Company, inc.
The Outcome
In 6 months, I researched, designed, and shipped the beta of the B2B SaaS product. The product supported 100K ARR from 5 enterprise customers (Record Labels) and kept our customers happy.
Here’s how we did it…
Step 1: UX Research & Product Discovery
With a limited understanding of music marketing and advertising, I started by getting to know music managers, marketers, and advertisers at Record Labels and pain points. My aim was to make sure the problem is real and worth solving. I aimed to answer the following 3 questions. What is the problem we are trying to solve? Who experiences this problem? When exactly do they experience the problem? I conducted multiple surveys, conducted numerous interviews, and led focus groups (as seen in figure 2) with multiple marketing teams. I relied heavily on the “jobs-to-be-done” research method and user journey mapping. Here is an abbreviated list of guiding questions that guided the conversations and workshops.
When was the last time you worked on a successful music marketing campaign? Can you tell me the story? What happened? Who was involved? How did you know it was successful? Were there moments that felt particularly tedious or challenging?
As a result, my research revealed the core problems music markers experience when running campaigns, success metrics for campaigns, and opportunities for product features to empower them to find success earlier and more reliably.
To document and synthesize my research I used Dovetail, Confluence, and Figjam. I frequently used User Journey Maps (as seen in figure 1) to organize research and discover product opportunities.
What we learned
Music marketers are not data analysts, but they rely heavily on data every day to measure success. Ascertaining and sharing data stories is central to their day-to-day work, but they struggle to find efficient ways to get the information they need quickly. They spend about 4 hours per week just exporting, cleaning & formatting spreadsheets and don’t automate anything with formulas.
The marketing team (and company) team valued being data-driven, but they often didn’t know how or didn’t have time to figure it out, especially when the data was coming from a bunch of different sources - Instagram, Spotify, youtube, google ads, Facebook ads, Tik Tok, shazam and chart metric, to name a few. A marketing director once explained, “Our data is like a weather map, and it’s my job to predict the weather.” This idea alarmed me because weather predictions are often unreliable and impossible to forecast. Understanding the success of a music marketing campaign should not feel like reading a weather map; it should be definitive and unequivocal. As a result, our leading design questions became:
1. How might we make it faster and easier for music marketers to make data-driven marketing decisions?
2. How might we make data analysis feel definitive and unequivocal?
Discovering these questions helped us narrow the scope (and timeline) of our MVP and gave us a measuring stick to assess the quality of the product.
Step 2: Site Mapping, User Flows & Wireframes
With a clear problem statement, a scope of the problem, and a definition of success, I started writing user stories, sketching wire-frames and mapping user flows to land on a few possible product features. I worked quickly, iteratively, and collaboratively. I led design workshops and design critiques frequently with the lead engineers and CEO. We used crazy 8’s to think quickly and landed on a set of wireframes that met the needs of our customers.
My design approach is heavily inspired by “SPRINT,” Jake Knapp’s great book on design sprints and prototyping.
Step 3: UI Design & Copywriting
With a clearly defined solution and low-fidelity wireframes outlined, the question was - how should we design the information and write the copy on each page to make it easy as possible for the user to have enough context and get to value faster? Considering branding, accessibility, and usability, I created a design system and wrote all the copy for the beta product.
Design System
The system included error messages, button & hover states, and typeface guidelines. Most of my design system is inspired by Google’s Material Design Guidelines.
Copywriting
Inspired by April Dunford’s book, “Obviously Awesome,” I tried to position the product to empower our users. My copywriting aimed to answer the questions - what does our product allow our users to do? And how can we align the tone and quality of the writing with the overall objectives of the product?
Step 4: Prototyping & Usability Testing
Challenge
How do we turn these 2D mock-ups into a usable & validated prototype?
Solution
I made a sample prototype with real data customized to each record label so that the prototypes seemed as real as possible. However, the product is pretty much all dashboards and rows of data, so recreating the whole product manually with real data would have taken forever. For example, I would have had to manually make 22 versions of that global heat map (figure 2). To save my time and preserve my sanity, I only updated the data for 1 artist in 1 date range - enough information for 1 complete marketing report. Then I scheduled 3 meetings with music markers for a “product demo.” During the meeting, I gave each user a challenge designed to test the core functionality we designed and keep users on the screens we wanted to test. For example, one challenge was “let’s imagine it’s Wednesday morning and you have to create a music video report for Justin Bieber’s new music video for your 10 AM meeting, what would you do?”
When the users took the wheel, it became pretty clear where the usability issues were. I tried my best to let the users figure it out/ struggle for a bit to maximize learning without pissing them off - that’s never good. I went through 3 different iterations of our product navigation over the course of a week with 4 usability sessions before I felt confident that it was a simple and intuitive navigation experience.
In addition, the product demos/usability tests were an excellent way to get users to buy into the product and manage their expectations. In my experience, helping users feel like they are a part of the design process and reminding them that this product is designed to make their lives easier gives them a sense of ownership that can alleviate the frustration when features inevitably break or take longer than expected to ship.
Onboarding
Navigation
Step 5: Build the Backlog
Challenge
How do you get this into the users hands as quickly possible?
Solution
The short answer is that you write crystal clear acceptance criteria for developers, outline test cases, conduct a robust QA (quality assurance) process, religiously hunt for bugs, and sometimes stuff still breaks or takes longer than expected.
That being said, this process becomes a lot easier when the prototype has real data that can be tested against and animations/transitions have already been designed in the prototype. Typically, I prefer that developers write their own tickets, but in this case, I worked with a lead dev to break up the prototype and prioritize work for the upcoming sprint. Documentation is tedious but doing it thoughtfully and carefully saves weeks of development and tons of meeting time.
As a product manager, I prioritize functionality over perfection and try to stick to principles inspired by the “Lean Start-Up.”
Step 6: Launch & Learn
After 6 months, we had a reliable and usable product that we felt met the needs of our customers. We onboarded 3 record labels in a month after a soft launch (!!!) without any major hiccups, received uneventful congratulations from a few folks, and went back to the drawing boards to continue to improve the product. Rinse & Repeat.
Like what you see? Let’s connect.
stephenkgleason@gmail.com