Leader Spotlight: The difference between a product vs. project mentality, with Brad Bowers
Brad Bowers is Director, Digital Product Management at Pampered Chef, a direct-to-consumer business that sells cookware in the US and Canada, as well as Germany, France, and Austria and also provides tips, tricks, and recipes to augment the mealtime journey. He began his career in application and implementation consulting for companies such as Cyborg Systems, Hewitt Associates, and Capital H Group. Brad then transitioned to redbox, where he became a senior program manager, and, later, a product manager. Before his most recent role at Pampered Chef, he served in various product and leadership roles at Kapow and Kin + Carta.
In our conversation, Brad talks about how a product mentality focuses on the goal you’re trying to achieve, whereas a project mentality focuses on traditional components like deadline, scope, and budget. He shares his perspective on the unique aspect of digital experiences at Pampered Chef — serving both consultants and end users. Brad also discusses why he subscribes to a ‘rent before you buy’ product philosophy.
Gravitating toward interesting challenges
To start, could you talk about your approach to integrating user experience design and data-driven decision-making in your product management process?
Fundamentally, I don't feel like you're doing product correctly — or at all for that matter — if you don't incorporate those two things into it. If you don’t integrate user experience design and data-driven decision-making into your process, you're more or less a feature factory — you're execution only. Nowadays, technology and product organizations have evolved into being thought leaders. We come up with ways to solve problems that work for customers, as well as the business. There needs to be a fundamental partnership between business partners and technology and engineering.
My approach is to think about things in terms of outcomes versus outputs. I like to flip the paradigm further and think more about what I would call “products versus projects.” Even though products have a timeline and a specific output associated with them, the focus should be on the goal you're trying to achieve and the problem you're trying to solve. That's more of a product mentality.
In your role, there are so many different stakeholders. Is there one product initiative in particular, from any of your roles, that stands out for you due to its complexity?
I've always found myself gravitating toward interesting challenges that don’t have a simple solution. At Pampered Chef, we sell kitchen products directly to consumers, but by way of our consultants. Our consultants are essentially our virtual storefronts.
Our consultants are the voice of Pampered Chef to the everyday consumer, and they're the experts. As a result, the challenge is more ambiguous for us — how do we ensure that we create a great ecommerce site experience that caters to the needs of the person shopping for a kitchen product or kitchen tool, while also doing it in a way that elevates the needs and value of the consultants?
Engaging with consultants and end users
So it sounds like consultants are essentially another user group that you need to consider and collect feedback from. Are there certain tools and methodologies that you rely on for collecting feedback, whether from consultants or end users?
There are a number of different tools, and we’re lucky to have such engaged consultants (or virtual storefronts). It's the most effective business I've ever been in — we’re able to truly engage with our users. They are more than willing to share their opinions and thoughts, as well as help pilot new products or features.
Qualitatively, we have councils that we regularly reach out to as a way to engage our consultants and understand what’s working and what’s not as we build tools to support them. We ask their thoughts on new ideas or how they might tweak certain products.
We also collect consultant feedback regularly. We try to do the same with customers, though like with every business, that tends to be a bit more difficult. We're always doing interviews, conversations, and focus groups. We use session replay to monitor how users are performing, identify their pain points and where they’re rage-clicking, etc. We've used it specifically in the context of checkout to call out any issues on our site, which leads us to be able to fix them quickly and identify the root cause.
In general, we are what I would call a “high intent business,” meaning if someone's coming to buy from Pampered Chef — especially if they're associated with an event, which we call parties, — then the likelihood of them purchasing is usually high. They come to our site to support their friends, family, etc., maybe they’ve got a discount, or they’re just looking for really high-quality kitchen products. Generally, there is an aptitude to buy, but the question is how much and what are they going to purchase. We need to focus on that last mile of conversion — the cart and checkout — so that we can optimize the experience and ensure that no one encounters any issues doing the basics.
How do you approach adding stickiness or finding ways to encourage users to view related items and potentially increase average order value?
We approach it with an element of personalization on both the product and people level. The interesting thing for us — and the evolution we want to take — is that in terms of how our consultants are engaged with their consumers, we have a lot of insights into consumer-centric behavior. For us, it's really important to take that into account when customers are shopping. For example, if a customer went to an in-person or virtual event, how can we better elevate the products that they saw there?
It’s more than likely that the products that were demonstrated to customers interested them. So, we can assume they might be interested in purchasing tangential products. For example, say the event included a demo of a pizza cutter. Well, pizza stones are one of our historically popular products, so we would recommend products like that.
Using JTBD and removing friction
Can you describe a time when using the Jobs-to-be-Done (JTBD) framework helped you pivot or refine your product strategy?
I think about JTBD less as a framework for strategy and more as a way to pivot. We use it more granularly from the feature evaluation perspective — to really understand what users want to accomplish.
One of the things we're evaluating is how we can best surface product content. For example, we offer kits for purchase as a way to join the business and start a consultant’s journey with Pampered Chef. We wanted to figure out the right framework to display information during the agreement and checkout part of this process.
We initially thought that the prospective consultant was trying to purchase this specific kit and had a certain thing in mind. But, in our conversations and research, we found out that the intent was slightly nuanced in what they were actually looking for. This understanding allowed us to change how we surfaced and displayed this information and led us to evolve what the kit mixture looks like holistically.
In general, JTBD has helped us understand the problem we’re trying to solve, which is something we can’t always get through quantitative data. And on the UX role side of things, I’ve found that you have to distill it down to the root cause. That's fundamentally what I think JTBD is really about.
Can you share an example of a time you identified a significant friction point in a user journey and how you optimized it? What metrics did you use to measure the impact of the change?
There is no place more apparent for friction than the conversion funnel. As you can imagine, people come in at the top of our funnel and can go every which way. As they begin to identify and add products to the cart, we want to convert them as quickly as possible. One of the things we realized throughout our cart and checkout optimization initiatives was that people were encountering different problems in certain steps of the process. For example, they were getting tripped up by an address field or were having problems with a specific payment method.
This wasn't something that everyone was experiencing, but we were able to flag it through our error analysis tool. We got to the root cause of the issue by understanding the context of the checkout conversion. What's unique about our business is that there are so many different cart experiences because we serve both consultants and end users. We may see hosts experiencing a problem with the checkout cart, while guests don’t have any issues.
The metrics we look at are relatively global in nature, but we have nuances that break down the experience in different carts. That’s pretty unique to our business. We anticipate different changes in metrics based on the carts, and we always explore why one particular person behaved differently than another.
Having everyone ‘experience the business’
You mentioned using surveys and focus groups to collect qualitative data from hosts and end users. Do you do on-site visits where you attend the parties that your consultants host?
Yes. One of the things that's important for not just folks on my team, but everybody in our organization, is what we call “experience the business.” For my team, that means that we will experience what it's like to work in our distribution center. We'll go in, pack boxes, etc. It gives us an understanding of how that all works and builds empathy for another department. We'll also do rotations to help with things like tech support, general customer support, product support, etc.
We get really valuable insights, and most people, particularly in my role, get to experience a lot of these parties. There is a mix of virtual and in-person events, so it's really interesting to get insight into how consultants run their businesses and engage with consumers.
We'll also do what we call “diary studies” or “day-in-the-lifes.” This is less about the party experience and more about how we understand what it's like to be a Pampered Chef consultant and run your own business every day. We tag along with them to understand how they follow up with customers or plan a party. It’s all fundamentally important and helps us get to the root of the biggest pain points that our storefronts have when it comes to trying to sell Pampered Chef products.
Does that help in the design of your digital experiences as well?
Yes, it helps us understand what we can do online to better provide to our consultants. As you can imagine, it also helps our physical product management team, which builds out our great kitchen tools. They’re able to get feedback on the interesting things folks are hearing about in our space. That’s one thing that we do at Pampered Chef that I especially love.
‘Rent before you buy’ philosophy
As you hear feedback from consultants or hosts, what's your process for prioritizing all of that feedback?
I use a variation of the RICE framework that we call PRICE. It stands for priority, reach, impact, confidence, and effort. We use each of those five lenses to gather a relative score as it relates to an idea or feature. For larger initiatives, that's where you start to get into business cases. This is where that products versus projects mindset comes back into play. We might just have a hypothesis, so I try to focus on building business cases around the problem area. Then, I can determine if it’s worth us trying to solve that problem using the PRICE framework.
We keep all of these things in mind, but the foundation of everything we do lies in continuous discovery. We should always be performing new and ongoing research. It shouldn't be project-based, but rather a constant focus of our research team, UX team, and product managers.
You subscribe to a ‘rent before you buy’ product philosophy. How has this approach influenced your product development and go-to-market strategies?
I didn’t originate this concept, but the idea behind it is about incremental work versus big-bang work. The UX manager on my team uses the phrase “better is better.” It’s crucial to always think about incrementality, so the idea behind “rent before you buy” is that you should always be trying to figure out the smallest thing you can do to validate your hypothesis. This can be in the form of an A/B test, prototype, etc. — you want to put something in front of people to get some nuanced feedback early on.
It's so much less expensive to change and pivot early on in the process than it is after you've built something. The sooner and the more you can validate both quantitatively and qualitatively, the better decisions you are going to make because logically, you've had multiple points to check whether you're headed down the right path.
You can use this method to test whether what you’re working on is helping you move down the path toward the outcome you're going after, rather than just releasing a feature for the sake of it. Though it’s great to release something, it shouldn't just be about the release — it should be about the impact that you're able to achieve and articulate.