Leader Spotlight: Transitioning teams to an agile mindset, with Clark Woolstenhulme

---

Clark Woolstenhulme began his career as a software developer at Novell and Rigaku Americas, then earned an MBA to facilitate a transition to product management. He worked at Bose Corporation for eight years, where he rose to Director of Product Management, then had stints as Director and then VP at Qualcomm and ZAGG, before his most recent turn as Product Lead at Bose Professional.

In our conversation, Clark talks about how he’s introduced agile to companies that hadn’t used it before, as well as the challenges associated with that transition. He discusses the importance of proper documentation and keeping historical records so product managers don’t have to guess why things were done a certain way. Clark also shares how he promotes a culture of thorough feedback to better his teams personally and professionally.

---

Moving teams from waterfall to agile

You’ve introduced agile workflows to four different companies that traditionally used waterfall. What was that like?

In most cases, the introduction of agile was motivated by a desire to modernize and better deliver high-quality code on time. At Bose, we were evolving into a place where our hardware devices — such as speakers or headphones — were getting more sophisticated and could connect to a phone or the internet for updates.

We had been pushing software updates over USB sticks for years with limited success, so we needed to be able to get these more advanced products on time. We had manufacturing schedules to meet but often didn’t get all the bug fixes or key features in by the time of launch. Delaying a hardware launch with so many features stacked for a huge release is so painful.

Later in my career, I worked for Qualcomm, and we were doing the same thing but on a scale 10x larger. If we were building at external semiconductor fabricators, for example, we’d have to schedule those tape-out times years in advance. We had to build a shared understanding of what the MVP would look like and then understand what features we could add or bugs we could fix afterward.

With Bose being such a huge company, what were the challenges of implementing agile across your teams?

In all of these cases, the main challenge was always recalibrating our project management to deal with the fixed schedules of hardware management and the ambiguity that comes with agile scheduling. Leveraging agile didn’t mean we could easily lay out the 217 things we were going to have done by January 2027, for example.

That was always the biggest growing pain — the organization asks for that commitment and that certainty. The organization also has to live with the uncertainty of agile.

When considering scope, cost, and time, you have to pick two of the three. You can choose what you want to flex, and we typically chose to flex scope. The organization still wanted to fix budgets, resourcing, and the schedule, so that meant the product management group had to be very smart about how we flexed scope. In every case, we had to be very clear about what our priorities were, what we really needed to accomplish to get our product out the door, and what could come afterward in an update.

Allowing for more flexibility

With the products you managed at Bose and Qualcomm, you dealt with a lot of tight restrictions around manufacturing, for example. You mentioned having to flex scope — what impact would that then have on a software MVP?

One of the most useful parts of saying “let’s use agile” is that agile is like a magic word. Saying it actually allowed a mindset shift in both the software teams and the product teams, and to a lesser degree, program management. Everyone could then say, “We are intentionally making the scope flexible.” We were throwing away the expectation that whatever the product manager writes three years in advance of the product launch will be what we commit to in terms of timing, or scheduling forever.

Essentially, it gave our teams the willingness to accept the reality that we can’t predict the future that tightly, especially when the budgets are never giant slush funds full of unlimited money and resources.

How did that prepare teams or modify their expectations around the product development process?

Agile asks teams creating an MVP to think long and hard about what creates value. What’s really necessary? This allows both product and engineering teams to have the conversation about where to start, which in our case was usually security and firmware update infrastructure.

As long as we had all of that right and were confident that we could successfully execute a software update, that already would buy us two months at a company like Bose. We’d have two months while we started producing the units, three months before they were en route to where they needed to go, and four months before they got into users’ hands.

Depending on the product, we still had to determine whether or not it was acceptable to push a software update the moment the product was first plugged into the wall in the user’s home, but acknowledging that we didn’t have to have everything done from the beginning changed our mindset. We knew we could be flexible and deliberate about the order in which we deliver these features. We spent time deciding what needed to be perfect from the beginning — right out of the gate — and what could wait a little longer.

When product managers become anthropologists

What kinds of things go into the process of developing requirements management paperwork or documentation?

I could be accused of being more heavyweight with documentation than many of my peers. It’s not that I love it more than the average person, but I tend to be verbose. I tend to err on the side of being super clear so the engineer reading it later doesn’t get confused.

One of the most problematic things I’ve encountered, especially when I was working on a few product lines at Qualcomm and Bose, was when an ecosystem had a long history. By long, I mean 10–15 years of something working a certain way, and we would have to either update it or replace it.

At that point, nobody at the company understood why some parts of the ecosystem or platform were a certain way. There would be no written record of why the parameter was set the way it was. And if you never wrote down what the customer wants and why, and instead only wrote down what it needs to be, then you lose that historical record. Product managers then have to turn into anthropologists, digging through what records they do have and guessing and theorizing.

Why do you think having that historical data or record is so important and integral to product management? Having that context for why something exists the way that it is is important, but it’s also kind of important to challenge that.

I took a great course about strategic decision-making in college. The whole premise of one of our textbooks was that history doesn’t repeat itself, but it does rhyme. You’re not blindly repeating the actions of the past in hopes that it’s going to work again, but the context will help you figure out what to do. As product managers, the true understanding of the customer comes from that institutional knowledge. I want product managers to be deliberate about it.

You can’t predicate the success of your business on having one genius who’s been at your company forever. Product managers need documentation to understand how user needs have evolved because that understanding allows you to see what users are asking for today. You can then have the confidence and data to rip up the old playbook from the past and completely redesign something new. Or, you can decide to serve this new customer need with a slight modification of the product.

The responsibilities of a good product manager

What do you see as the responsibilities of somebody who is a good product manager, and what do you think those qualities bring to a larger team?

I think good product managers are, first and foremost, excellent diplomats and negotiators. We are at the intersection of many different organizations, efforts, and flows of information. Each of those groups will have constraints that may be two or three layers removed from the making of the product. So, you need to be able to negotiate to drive the company toward a successful place in light of the current state of the company and any constraints it may have.

Following that, I find attention to detail to be crucial. There are so many core competencies that I look for, but the overarching one is the ability to think big, think long-term, and organize and synthesize ideas into a roadmap. I know that’s big and airy, but if you can tell folks the next three steps ahead, it’s a lot easier for them to chart the course of the solution.

It’s not about predicting the future — it’s about choosing a path that makes sense, meets the financial metrics of the company, and aligns with the strategy. You have to balance all of those things.

Where do you see tools like generative AI fitting into that? Many people imagine that AI can write the documentation of a feature and it’ll come out clean and perfect from the gate. Why is that a problem?

It’s a problem because I feel like with generative AI in particular, we’re still in the “trust but verify” phase. I experimented with this recently when I asked AI about some security requirements. I wrote, “What should be the security requirements for this particular set of products?” It was able to give me a list of security standards, but it had no idea how to connect them to the actual products. All it was capable of doing was finding security standards that people talk about a lot.

In my opinion, the worst thing you can do is think that because you have bright ideas, AI will take care of the rest. Today, the best thing AI can do is generate a framework for you to structure your thinking. It’s very good at that. AI is a time saver right now, and it is a way to expand your thinking, but the core competencies of product managers in being very detail-oriented and negotiating is what actually makes a good product manager.

What have you seen as a successful approach for teaching other people these core competencies as they grow in a product management organization?

I spent a lot of time minting new product managers, particularly in my early days at Bose. I found that the most successful method is to first provide examples of good work. Much like machine learning, people learn best when they can see what is right and what is good.

You can’t take someone’s work and say, “I need you to do better,” if they don’t know what better looks like. I often kept a ready supply of product definitions — we called them PDs or PRDs. I’d keep the shining gold star examples handy, so when a PM would jump into a new category, I’d be able to reference them and say, “Bill wrote this one and Dan wrote this one. They are excellent.” And those are their real names, by the way — hi, Bill and Dan!

Implementing a culture of constructive feedback

You often hear people talk about the difference between a leader and a dictator when it comes to managing people. How have you practiced this culture of leading, not dictating, your teams?

As a manager, you want to avoid doing your employees’ work for them, but it’s OK to be an editor or a sounding board. At Bose, we frequently wrote white papers and briefs, so we would have an author or editor assignment for each of those projects.

Developing that culture around “you do the work, bring it to me, and I’ll make it stronger,” instills trust and teamwork. You can make things stronger together. That helps people learn by example and see the flaws in their thinking when they’re ready for review.

Further, we had management’s support to adopt a fairly aggressive feedback cycle. We would identify growth areas for each employee and hold them accountable for demonstrating them. For example, say someone wanted to get better at presenting. We’d say, “When are you going to demonstrate these skills? Who is going to witness you demonstrate them? I will go talk to them before and after.” I’d talk to that witness and come back to the person with aggregate feedback. This was an affirmative, critical layer of feedback, and it was great.

Feedback loops are so important, both for products and for professional development. Have you continued to use these practices today?

Absolutely. Feedback shouldn’t only be given when somebody did something so exceptional that they trigger someone to say, “I’m going to call their boss and give them a gold star.” And on the flip side, it shouldn’t only be given when something is so bad that their boss needs to be flagged. Creating a culture that says, “We’re going to look out for you — we’re going to observe and critically improve your performance,” is really helpful and stuck with me.

How do you convey that culture to other managers so that they know the difference between constructive feedback vs. being overly critical?

I try to be very clear with my people managers that the success of their team members is their success. I give them as much credit, if not more, when they help their team members do something great than if they do it themselves. Or, even better, if their team member does it and feels ownership to claim the credit they deserve. That’s what I want as a manager — you’re not actually as useful to the organization as a manager if all you can do is take credit for great people’s work.

You’re way more useful if you can find great people and turn them into better people. Those are the skills we look for. I’m always upfront with that. Of course, I do this same feedback with my direct reports to demonstrate what it looks like in practice.

The whole point of our organization is not just to grow revenue, it’s to grow the skills of the organization as a whole. To me, that’s essential and comes first. The revenue will come later.