Margaret Tuohy is SVP, Product Management and Design at PeopleReady, a firm that connects prospective employees with companies that have short-term staffing needs. Margaret started her career at GE Capital and has worked at Informatica, CNN, Business Insider, and ADP, as well as small and mid-sized startups.
In our conversation, Margaret talks about how digital transformation doesn’t always imply fixing an area that’s broken but, rather, taking a proactive approach to remain competitive in the market. She also discusses steps to take when dealing with disparate data, including aligning with a North Star and being able to find trends in the data to pick out what matters.
I think, in some ways, HR tech does have a unique flavor of product management. For example, within HR tech, an organization could have around 16 HR tools of some sort — payroll benefits, recruiting, etc. — in addition to their financial and CRM systems. When you’re operating in the HR tech space, from a product perspective, you really need to be building with a view toward how your product integrates with the client’s existing tech ecosystem.
I would also say that, as disruptive and innovative technologies are introduced, we’re still looking through the lens of how this technology helps solve a business problem or user need while remaining compliant and fair. That’s probably common across many industries, not just HR. For example, if we’re improving a recruiting product, we may ask how AI or LLM can add to the candidate’s experience? How do we measure for success? Are we monitoring for unforeseen consequences?
I think it’s impossible to completely future-proof some of the technologies. If you think about applications 20–30 years ago, they were built and architected to do everything — front office, back office, etc. A lot of these homegrown applications do everything. In some of the digital transformation efforts that I’ve been involved in, it’s about really unpacking that and saying, “Well, how do we instill modules around functional capabilities so that we can build APIs to have integrations with other tools?”
A lot of that is about re-envisioning the architecture but doing it in a more iterative way. You can’t just bust open a 20-year-old system without doing a fair bit of thinking, or else you can cause some damage. It has to be very methodical in how you approach it. We’re going to extrapolate this functionality into services. We’re going to use protocols and standards because other organizations are likely going to be using those same protocols and standards.
That’s a lot of what we’re doing at PeopleReady right now — understanding how to evolve our technology so we can leverage best of breed solutions and integrate as needed, while keeping what our own systems do well.
From what I can see, there’s a generic definition of using digital processes or innovative technology to replace manual processes. The reality is, that’s been going on since the beginning of technology.
What I’ve seen in digital transformation, and my last few roles have been squarely focused on that, is there’s a certain amount of scale involved. It’s not necessarily an individual initiative. There are related initiatives to fundamentally change the way that part of a business works. That could be using disruptive technology for the benefit of business outcomes.
I think there’s also a big cultural component. Fundamentally, it’s a company saying, “We’re not going to do things the way that it has been done for decades.” And it may not even be a particular area that employees think is broken, it might just be a necessary change to stay competitive. So in some cases, it can be very proactive.
I think anything with technology is iterative. I have never been in a program where you can say that we’re just going to set it and forget it. Even when technology is operating well, let’s say if it’s at a high level of maturity and efficiency, there’s always going to be a need to evolve, tweak, and improve. So I don’t think digital transformation is ever done.
I also think that in areas you might have transformed today, you may need to look at another part of your business tomorrow and decide to focus on it. But I do think the danger with digital transformation is that, in my experience, it has led to these big programs and big projects that get approved and are multi-year. There’s a real danger with digital transformation that it almost becomes waterfall, and that can’t happen. Determining how to remain agile is paramount.
You really need to be conscious of how you’re testing this transformation and how you’re keeping the program agile. Because sometimes, the scale of it almost hides that. And as product managers, it’s something that’s even more challenging with a digital transformation program versus working on one specific feature for a specific product.
When I was at ADP, we were looking at how to improve the payroll experience. One area was making that payroll experience more self-service oriented. We separated features into buckets that made sense to group together. We’d test that out, prototype it, and roll it out to users to see what some of the business improvements were. Did we see adoption? Were we seeing the time savings that we expected to see? Were we seeing the amount of errors going down and doing that with a subset of the experience?
That highlighted areas that we needed to refine and where we could go in other areas of the experience. So rather than saying, “We’re going to redesign everything all at once and launch it,” we looked at what made sense to deliver such that it actually will have an outcome that we expect in time savings or fewer errors. We can test that, improve where necessary, and move on.
I think it can have a big influence. I was the first product person for the business news unit at CNN. I started out as a generalist and, as we grew, I had the opportunity to make my first hire to help split the workload. That led to organically building a small team that complemented each other’s skillsets. Conversely, when I was at ADP, we had a larger product management organization where there were a couple of hundred product managers. Things like skills, competencies, and career paths were a lot more defined than when you’re one of the first few product managers.
PeopleReady is kind of in the middle. When I took the role two and a half years ago, I had a relatively new team. We didn’t necessarily have a roadmapping approach or our product management skills and competencies laid out. We evolved our roadmap approach starting with one team, got the kinks worked out, and then other teams came on board. The product management team members were very involved in this process — it was not top down. For example, we had group discussions to learn what skills product managers needed to be successful in this environment.
As a product manager, you need to decide if you’re looking for an org where product management is pretty well defined, or if you want to be more involved in creating the function. That’s also important as a leader. When you’re going into a mid-size organization, don’t underestimate the effort it takes to develop artifacts and processes that may have been table stakes in your prior role. You have to understand if you want to sign up for that. I think the size of the org really can impact those types of day-to-day activities.
Sometimes, when you read interviews with product managers or you see the PowerPoints, everybody tells a very compelling data story. You think, “Wow, the data’s clean, it’s 100 percent. It’s pointing in a very clear direction.” In my experience, that’s not always the way things work.
At a previous company, I had taken over an initiative that had a poorly rated mobile application. Reviews said “This app crashes,” or “This app’s performance lags,” and we had no performance tracking information on it. Before adding new features, we had to say, “We’re going to set up, instrument, and buy a package that tells us why the application is crashing.” While that example might seem dated in the age of performance analytics, I bring it up because sometimes, the roadmap has to include setting up data so that you can make future decisions. Instrumenting data is often not trivial and has to be considered in the early stages of feature development.
There’s a couple of things when you have the disparate data. First is establishing the North Star data that you’re looking for. Then, going in with those disparate data sources and saying that as long as directionally, they’re showing the same thing, we’re going to establish a fairly generous difference between these two systems. System A is not always going to say the same as system B. You’re very often not going to get two different analytical systems saying exactly the same thing. Can you say, directionally, that they’re showing the same trends?
Recently at PeopleReady, we were getting different data on onboarding and steps within the funnel. Despite the differences in data frameworks, directionally, we were able to identify a few areas to focus our improvements. We did not spend a lot of time reconciling the exact data differences between systems, because we recognized that in this instance, there wasn’t a lot of value in doing so.
The macroeconomic climate is a big variable in this, and I don’t want to downplay that. Training budgets can ebb and flow based on company size. Obviously, if a training budget is available, I do believe in taking advantage of it. Having said that, I am a big believer in learning by doing.
I think the first step for a product manager, or anyone really, is really thinking about where you want to grow in the next 12–18 months. You don’t need a five year plan! I know it sounds obvious, but honing in on one or two areas to focus on does take a certain amount of thought and reflection. When that’s communicated with me as a leader, it helps me look for ways to have the person work in that area, or at minimum, get more exposure.
If I know someone is looking to advance in data analysis, I may be able to give them a small project where there is a need. If someone is looking to develop into a leader, I may give them an opportunity to mentor or get them more exposure to the budgeting process.
Within the product managers in my team, when they are doing an analysis, I try to have them present the analysis to senior management so that they can hear the feedback. I think it is also a chance for them to shine. I will absolutely prep them, critique their work product, and walk through it before they make the presentation, but I try to have them do the presentation to get that exposure. I think that’s a really nice thing about PeopleReady — there’s that opportunity. It’s making it part of their jobs so that it can have an impact on what they’re trying to influence.
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?
Scenario analysis is a strategic planning tool that helps you envision a range of possible future states and the forces behind them.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
Learn more →
