Product Operating Model
Current results:
“Empowered product teams are given problems to solve rather than features to build.” — Empowered
The Executive Summary
The Product Operating Model transitions our teams from feature factories (delivering outputs on rigid roadmaps) to empowered product teams (solving meaningful problems to achieve business outcomes). In this model, Design is not a service agency or a "paint department" that beautifies specs created by product managers. Design is an equal co-owner of product strategy, discovery, and delivery. There are several philosophies we followed, I'll list them out, and explain how our triad followed these principles, and what we learned
1. The Core Philosophy: Missionaries vs. Mercenaries
Traditional feature teams operate as mercenaries: they build whatever features are handed down to them on a roadmap. Empowered product teams operate as missionaries: they are given business problems to solve and outcomes to hit, with the autonomy to figure out the best solution.
What we did:
We knew that the scheduling experience wasn’t the greatest. Our products rely on our users ability to create schedules, monitor their workers, and have accurate reports created from their punches that are then mapped back to the schedule for billing & payment. The business problem? We didn’t know how our users were scheduling, what their biggest issues were, why they used Tg+ the way they used Tg+, and where they were spending the majority of their time. For our initial pass, we worked with our CSM’s, SME’s and our PM to create some OKR’s that we thought would be great to see from our endeavors, and wanted to narrow this list down to 3 that we want to validate with our users. What we didn’t know, is that we ultimately would only keep 1 of these original 7…
Next, we developed an Opportunity Solution Tree (OST) to clearly map our strategic direction and ensure alignment with our overarching objectives. OSTs are valuable tools for maintaining an open perspective, encouraging exploration of diverse and improved solutions to achieve the desired outcome. They also provide stakeholders with a transparent view of the high-level strategy and the main focus areas under consideration. For those unfamiliar with Opportunity Solution Trees, Teresa Torres offers an insightful and comprehensive overview here.
Lastly, these two tasks gave us a direction to start looking. We knew we had a problem with our scheduling taking too long, other companies were popping up and taking our business with slick scheduling software that visually looked better, ran smoother, and felt more modern. We had highlighted a few areas where we believe we could make a big difference, but what we believe doesn't matter. What do our customers believe? We needed to find out, which brings us to our next principle.
Product Design’s Dual Role: Discovery & Delivery
In the Product Operating Model, Design balances two continuous streams of work: Discovery (finding the right thing to build) and Delivery (building it right).
A. Continuous Discovery (Where Design Leads Strategic Value)
Designers do not wait for a PRD (Product Requirements Document). Instead, designers actively participate in:
Weekly Customer Exposure: Participating in at least 1–2 customer interviews or user sessions every single week alongside the PM and Engineer.
Rapid Prototyping: Creating low-to-medium-fidelity prototypes to test value and usability assumptions before writing production code.
Problem Framing: Helping map customer journeys, service blueprints, and opportunity solution trees to identify the root problem before debating solutions.
B. Continuous Delivery (Ensuring Craft and Scalability)
Design System Integration: Leveraging established UI foundations to accelerate delivery and maintain product-wide consistency.
Design QA: Partnering closely with engineers during sprints to verify that interactions, responsiveness, and edge cases meet accessibility and quality standards.
Iteration Based on Telemetry: Analyzing quantitative usage data and post-launch feedback together with PMs to refine features after deployment.
What we did:
The biggest lesson here was that our customers actually loved talking with us and seeing our prototypes. We usually carved 60 minutes out of their day, and they almost always showed up with a smile and excitement in helping us desing the future product they use daily. Let's start with discovery, we met with a minimum of 1 user per week, often 2, but seldom more than that. We aimed for 1-2 a week, and would go in waves. The first wave was an introduction, we had a script of non-leading questions to ask, to get to understand how they use our scheduling software. We'd record the meetings with an AI note taker, and then combine all the notes into NoteBookLLM which we could ask questions, visualize our data, and make sure every detail was captured when scraping for certain topics.
Prototyping as a shared Language
PRDs and static documentation are inherently ambiguous and prone to misinterpretation. Interactive prototypes serve as the team’s single source of truth: aligning stakeholders, guiding engineering, and allowing real users to experience the solution before code is written.
What I do:
Prototyping Strategy: Use AI tools to speed up the process from ideation, to high-fidelity prototypes to experiment with users. It starts with scraping the data from our user interviews and documentation into patterns and repetitive priorities. We then use our Gemini Gem created for our project, and ask to produce prompts to give to figma make to achieve our goals. These prompts are put into Figma make and tweaked to fit the goals of our experimentation. Figma make is hooked up to our design system, so the output already looks like our product.
My Design Actions: From here, we can publish the prototypes to a shareable URL to have ready for our next round of interviews, or usability testing depending on the experiment. We also share out the prototypes to stakeholders to test and be aware of our progress
Outcome & Business Impact: Faster alignment, ability to fail fast, clearer developer specs, fewer edge-case surprises in production
Falling in Love with the problem, not the solution
Great product teams resist committing to their first solution idea. They explore multiple paths, test diverse hypotheses, and are willing to kill weak ideas quickly in Figma rather than in production. Hence to often used tag-line "Fail Fast".
What I do:
Exploration & Iteration: I explore the problem by really poking holes in what we think the problem is. Talking to our users is the fastest way to do that. We run user calls as often as we can, aiming at 1-2 per week at a minimum. A script that follows a "choose your own adventure" book is written with a focus on non-leading questions, and opportunities for our users to do all the talking, and showing of the problem in question.
My Design Actions: Compare alternative user flows, testing multiple interaction patterns, killing flawed ideas early based on user testing
Outcome & Business Impact: This method produces much better results compared to our previous method of producing what we think our users will want, and going with one solution based off of a problem. If our users have vetted the solution against multiple iterations, they have essentially proved our solution as the most viable for our use case. This leads to better adoption, better retention, and a better experience for our team since we don't have to re-do work that ended up being sub-par
SUMMARY
Move from feature delivery to outcome-led collaboration. The trio owns the problem together, then carries that shared understanding into delivery.
KEY TAKEAWAY
Start with the problem, not the feature. When the trio shares ownership of discovery and delivery, every prototype becomes a step toward alignment.
SOLUTION
Make the learning loop visible: bring customer evidence into the room, define the outcome before the output, test early, and let telemetry guide what happens next.