Emmett Ryan is Group Product Manager at C.H. Robinson, a logistics and supply chain company. He began his career as a business systems analyst at Ameriprise Financial Services before joining Travelers as a data warehouse production support manager. From there, Emmett transitioned into product management with the company, where he later led the loss data management practice. Before his current role at C.H. Robinson, he served as a product manager at Insurity, a cloud-based software for insurance carriers, brokers, and MGAs.
In our conversation, Emmett discusses how he helped introduce agile processes at C.H. Robinson, resulting in improved accuracy of project estimations and better qualitative feedback from stakeholders. He shares why he believes that “every problem is a people problem” and the importance of understanding people’s personalities to create a healthy team dynamic.
Some of the biggest challenges I’ve found are siloed orgs within an enterprise, as well as ingrained biases. In every org I’ve worked in, each department thinks what they’re doing is the most important thing. It’s a little bit different from, say, a startup — or some more modern tech companies that operate with single-threaded leaders, where everyone on that team has the same objective — because you need all these groups working together to make the output fantastic.
It’s critical to understand where people are coming from, what the end game is, the outcomes each of these departments are looking for, etc. That ties into biases, not to mention incentives, as well. I started working in product when I was at Travelers. It’s not really what we think of as product nowadays. We had to slowly reshape the way we talked about our org, reframing it as a product organization. We gradually started to exercise that muscle, but a lot of people didn’t understand what product management was. We already had project managers. So why did we need a product manager to come in?
Let’s take a look at where I am now at C.H. Robinson. The division I’m in specializes in end-to-end item-level management. We have product managers focused specifically on sourcing and buying produce like grapes and melons, which is a world away from my domain. You also have to get around the idea of the difference between a product manager and a project manager — a question I got a lot when I started. The project manager is judged on getting something done on time and on budget, whereas a product manager’s objective is all about building the right thing.
The ability to prioritize and have laser focus is critical. The problem in legacy organizations is that there are silos. People have ingrained biases about how things should be, especially when some have worked at the company for decades. Trying to change their minds about how to do things is difficult. To do that, you first need to figure out, from the get-go, who your supporters are. Who are the people you can rely on to help you promote this new way of building in your organization?
People won’t believe it until they see it. You can give all the presentations you want, but until they see the new approach in action, it’s hard to change minds.
When I arrived at C.H. Robinson, they had just finished building a software tool implementation. It had taken about two years, and users were not fans of it, to say the least. It was a clunky user experience. It wasn’t as good as what they had before. I asked people, “But you got stakeholder feedback and brought them along on the journey, right?” They said, “Yeah, we gathered requirements, but then we threw the requirements over the wall and let the engineering team work on those for two years. And then at the end of two years, they came back with this UI.”
It’s like asking my daughter in January, “What do you want for Christmas?” She says, “I want a dollhouse,” so I go off and build it in secret. But by spring, she’s into robots or Pokémon, and the dollhouse no longer excites her. That’s the classic problem with how things were traditionally built, and how modern product managers need to build now. We need to ensure we are building the right thing as efficiently as possible with the least opportunity cost.
The two-year project building the UI — or the dollhouse — that’s waterfall. You gather a lot of requirements up front. You go through cascading phases with little or no feedback to course correct. You just wait until the end. So we got buy-in to change how we build by adopting agile. We have two-week sprints and ceremonies, and we build incrementally. We bring stakeholders along on the journey and update them in our sprint reviews every two weeks. If they say, “After two months, this is all I need. I’m happy now,” you’ve cut the time in half. That’s ideal. But even if it takes four months, you’ve still built up goodwill along the way.
I love the quote from Christian Idiodi from the Silicon Valley Product Group, “Every problem is a people problem.” It’s so true. People are driven by ego and want to be included. If you exclude a key stakeholder during the build, they’ll likely become one of the chief critics.
I love the book Surrounded by Idiots by Thomas Erikson. Erikson, originally a business coach and lecturer, heavily relies on the DISC framework, which measures someone’s behavioral preferences. There are traits for each of the colors:
This has actually helped me a lot. Some team members are quiet, reserved, and introverted, and I’ve had to slowly build relationships with them by asking questions unrelated to work.
You’re probably thinking that’s just being a normal human, learning more about your team. But others are very Red. They want to cut to the chase. Everything has to be outcome-driven. They’re less concerned with relationship-building.
Where I’ve seen this work well is in building team relationships. Don’t pair a Red and a Green together, for example. The same goes for a Yellow and a Blue. It has also aided in helping others understand that someone may not be angry. They might just have a Red personality. They’re energized by arguing, for example, whereas arguments drain Greens.
When I arrived at C.H. Robinson, we were in the middle of a big migration. I was lucky in a way. I had three or four months to observe. I saw what needed to change and what we could keep. There was a lot of good stuff to work with and a great team.
During those first months, I worked with a senior UX designer to conduct a lot of user research.We talked with internal users to understand what needed to be done and shape our roadmap. We weren’t doing agile at the time, so the first priority was to partner with the engineering team and put that in place. From there, I met with senior leadership. C.H. Robinson works on big, long-term projects, and that probably won’t change. But I showed them a slide of major projects and how they played out against budget.
I can’t recommend How Big Things Get Done by Bent Flyvbjerg enough. It covers everything from California high-speed rail to kitchen renovations. The most over-budget and overtime? Nuclear projects, followed by the Olympics, and in third, you guessed it, IT projects. People are just horrible at estimating complex projects.
I showed them how IT projects are often way over time and budget, and they asked, “How can we make this better?” The answer: find out if this kind of project has been done before and learn from it. Another key takeaway was that deep planning, while useful, can sometimes be at odds with agile. But no development philosophy should be dogma. Think deeply. Act quickly.
Senior leadership wants predictability. They want to plan, forecast, and project. But that’s hard when long-term IT projects spiral. So we set up four agile teams. We started with one pilot team, like an A/B test. That team worked in two-week increments and included stakeholders in reviews. The result? Agile led to more accurate estimates and better qualitative feedback. Stakeholders loved being part of the journey and the product’s evolution.
Again, every problem is a people problem. At the end of my first six months, the head of account management came to me and said, “The net promoter score from our biggest customer is really low. They’re not happy with our reporting and analytics. The dashboards are poor.”
Like with agile, I didn’t reinvent the wheel. I feel like my superpower is talking to people. It sounds simple, but so many people don’t do it. They’d rather push something out or send an email. I scheduled a biweekly call with the group’s manager and included them in all reviews. Previously, we’d only talk to customers when something broke. We became proactive instead of reactive.
That’s why I meet with all my key stakeholders regularly. I want to surface issues early. I urge them to invert their thinking. What’s the worst-case scenario? We explore that together. But ultimately, it’s just sitting down as humans and listening to what problems we’re trying to solve.
We estimate work in story points. It’s not a perfect science, and not something I love, but it gives us a baseline. One of the account managers needed a feature around “First Expired, First Out” (FEFO). Since we manage inventory, this means prioritizing inventory movement based on expiration dates.
The feature had been in the backlog before we engaged with the stakeholders or adopted agile. It was originally estimated at something like 50 points. One person can typically do 13 points per sprint. But once we brought engineers and stakeholders together and worked through the assumptions, the team came back with a version that met the need. And it only took four or five points. The customer was delighted.
Doing something like that is just as important as the big, strategic projects. If you can do even one of those every sprint, you’ll delight stakeholders. That goodwill gives you grace when other things slip.
The core idea I took from Drive by Daniel Pink is that people are motivated by autonomy, mastery, and purpose. Autonomy means getting out of their way. Give them the purpose — that’s the role of the product team. Get engineers excited about how their work drives the bottom line and contributes to the company, not just shipping features.
Mastery is about self-improvement. Most people want to get better. Our job is to give them the space to do their best work. That’s what I encourage with our teams. When we write user stories, we’re clear on the why. Who are we building for? We create user personas so that engineers are familiar with the customer. From there, we step back. They own the how, and they often find better ways to create outcomes.
It’s amazing to see it in action. These are soft skills, but they’re everything. I’m standing on the shoulders of giants like Marty Cagan, Melissa Perri, Jobs, Munger, and others. I don’t pretend this is all my wisdom. I just try to distill it and pass it on so the team can grow and get better.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
Suvrat Joshi shares the importance of viewing trade-off decisions in product management more like a balance than a compromise.
Great product managers spot change early. Discover how to pivot your product strategy before it’s too late.
Thach Nguyen, Senior Director of Product Management — STEPS at Stewart Title, emphasizes candid moments and human error in the age of AI.
Guard your focus, not just your time. Learn tactics to protect attention, cut noise, and do deep work that actually moves the roadmap.
Learn more →
