Leader Spotlight: Changing how people work, with Todd Buelow

---

Todd Buelow is VP of Product at online retailer Fingerhut. After an initial experience in digital transformation, Todd quickly discovered a passion for building technology that enhances the customer experience and changes how people work.

In our chat, Todd offers practical advice to help product leaders upskill their teams in agile processes and away from old waterfall habits, which tend to die hard — especially in large enterprises. He also talks about the benefits of involving UX design in the discovery process and the importance of having a dynamic roadmap so you can reprioritize as new market conditions and opportunities arise.

---

Building in expectations for agility

Can you talk about some of the projects you’ve worked on that have involved digital transformations?

A couple of years ago, we implemented a new digital asset management platform. You bring in a DAM and you’ve got a place now to store all your content – product images, promotional content, even documents. This has benefits right away. But then, with all the workflow and everything around that, you find new ways to improve your operations and change how people work by enabling automation and creating workflow.

It seems simple, but you’re always discovering new ways to influence the business after you put tools like that in place. This is one of the ways that agile product practices can really complete a digital transformation – you’re never really done improving.

How do you approach stakeholder management when trying to implement new tools and technologies?

One of the biggest things I’ve learned is to start with good agile practices in the product development process as part of the digital transformation. Obviously, that allows you to get smarter and iterate and kind of build better solutions over time. But one of the challenges is building agility into your expectations with your business partners.

Typically, you would have a change management component, whether it’s a dedicated change manager, which I’ve had in the past, or different folks playing the role of change manager in terms of that relationship with the business. This person should be building in expectations for agility as part of your change management administration. That means getting your business users used to new releases coming out every two or three weeks and setting expectations that solutions that you build are going to start off pretty basic and then become more sophisticated over time as we all get smarter.

If you can get to a state where that agility is aligned between the business and the technology, then it’s fantastic. But if you don’t, then it’s going to create a lot of headaches for you and it would either force you back into more of a waterfall mode of product development or lead to inconsistencies with what they’re expecting versus what they’re actually getting.

Of all the product leaders we’ve spoken to, I don’t think anyone has said they prefer a waterfall approach over following agile principles, yet many organizations still seem to be mired in their old ways. How do you strike the right balance when you encounter those situations?

You’re right: no product person would openly advocate for waterfall in 2023. But waterfall is kind of a headwind that you’ll have no matter where you are because a lot of leaders still think about projects in terms of waterfall.

It’s good to have North Stars, it’s good to know where you want to go, but you have to be open to getting better along the way. What you think is important now might not be that important 18 months from now. All these requirements you’re receiving from your business partners and solutions you’re coming up with — if you’re not reprioritizing them consistently, you’re setting everybody up for disappointment.

I think one of the other more interesting parts of your question is: if you’re in a startup or a company that develops and publishes software, there’s immediately an agile culture. There’s usually no other way to be successful in that environment. But when you’re a product manager in an enterprise, there’s kind of a bias toward waterfall projects because, often, “the business” just wants to build the thing and move on from it.

A lot of times, they don’t understand the benefits you can get from developing things internally in an agile manner — or, even more so, doing your digital transformations in an agile manner too. And it’s counterintuitive because, in an enterprise, you have customers who are much closer to you than when you’re building an app or a SaaS product.

Don’t get matrixed out

Can you speak to your experience building and growing product teams?

The last few years were pretty challenging for leaders looking to build product teams. On top of the technical requirements for folks we brought in, I had a few high-level criteria: ability to get things done, including some kind of domain expertise or adjacency; having a curious mindset, somebody who likes to solve problems; being outcome-driven or, at least, outcome-aware aware; and, of course, agile expertise.

I love the diversity we have on our team with their backgrounds, which industry they came from, and how they like to solve problems. It’s really fun to get everyone together and see what they can accomplish.

You mentioned the UX team reports to you. What are the benefits of having UX squarely in your purview?

One of the things we can do now is deploy the UX team across the enterprise. A lot of folks still see UX as “UI people” — drawing up interfaces, etc. But UX, when done right, is great at bringing the customer’s perspectives into places that aren’t so obvious. That was something I learned in an earlier role.

The other cool thing to do within a transformation is to define the customer as someone internal — they’re trying to get a job done too. Applying experiential design efforts to some of these “internal experiences” has been a neat way for us to approach problems.

Also, there’s always a tradeoff when it comes to having functional verticals versus using a matrix, and we’ve all seen this with different sales teams or engineering teams that get matrixed out. I think the biggest thing is to empower the cross-functional teams to be successful as a squad, as a product team. How you organize the different functional groups from a people leadership perspective, I think, is less important, as long as those squads are all empowered.

Do you think a product manager should have UX experience?

It wouldn’t hurt, just like it wouldn’t hurt for product managers to have development experience. There are all kinds of adjacent capabilities and getting a mix of that kind diversity on your teams really helps because you get all kinds of different perspectives in the room, and that’s where the magic happens.

I’ve found, too, that there’s a lot of fluidity in terms of these roles. You’ve got people who are super technical, people who are more customer focused, and some just organize and execute. Getting a good mix of all that is important to the success of the team.

The art of decomitting

What do you think is important to keep in mind when working on product roadmaps and the product vision?

The reason we’re here is to drive business outcomes. And as a leader, I have to keep our focus on the “why” to ensure we’re asking the right questions.

With our roadmaps, we use a methodology called intention mapping, which I learned from a past employer. It’s used by a lot of agile practitioners in the Twin Cities. It’s essentially an outcome-based roadmap that you are empowered to change as months go by.

In the old days, changing a roadmap was really a bad thing because you’re kind of decommitting to something that you committed to. But nowadays, if we decide something is more important to the business, hell yeah we’re gonna pivot as quickly as we can.

The Agile Manifesto says you have to be accepting of changes in scope, even late in the game, so that you can provide a pertinent, valuable solution to the business. And I think that’s the most important thing with roadmaps: they can be useful, but you can’t fall in love with your own solutions or your own plans because they are subject to change according to how the business changes.

How do you determine the right time to make changes to your roadmap?

It all comes down to the business value. You need to be able to let go of something that you spend a lot of time on — it happens all the time. Obviously, you don’t want to do that too much, but we revisit our plans on a monthly basis and talk about them on a quarterly basis, so that gives us plenty of opportunity to reprioritize things and be truly agile to the business.

So if the head of sales comes to you and says, I would close more deals if we built X feature. How do you respond in those situations?

I’d say, “You think you need this feature; why do you think you need this feature? Why do you think that feature would add value?” And then it’s a discovery process; you try to get to the bottom of what your client or your customer really needs, what kind of experience they want, and what kind of outcome that would drive. And then you level-set and work your way back to a solution. In many cases, yeah, what the business lead provided might be a very good solution.

Tying it back to how I got started in product, I had came to our hired consultant as one of those “smart” business guys and said, “Hey, I want a solution that does this, this, and this. Just build it and let’s go.” And then I realized there’s way more to it than that. She asked the right questions and probed me on what I really needed. The solution that we came up with wasn’t exactly what I had envisioned, and that’s what kind of opened my eyes to product management and led me down this road.

Back to basics amid the AI revolution

In your view, how are AI/ML tools changing the game for product managers, especially when it comes to things like personalization and segmentation?

I’m really excited to see what it can do for rapid prototyping, coding, and commenting. I think these capabilities should really increase the velocity of building solutions. Maybe it will help us create designs faster than before, too.

But, for now, it seems like product discovery will remain a human-driven conversation. Either way, AI/ML is like any other digital transformation tool — how can we use this technology to automate the drudgery and free up our people to really add value in the way that only they can?

On that note, what do you think will be important for PMs in 2024?

The basics. It’s wild to me that the Agile Manifesto was written over 20 years ago, but still so many companies still don’t really practice agile very well. And many have no clue about the value of thinking this way, still. That suggests there are a lot of opportunities for PMs to have a big impact on the world or on their companies as we continue to move forward by just continuing to do their PM thing, and doing it right.