Leader Spotlight: Applying an ROI model, with Jason Penkethman

---

Jason Penkethman is Chief Product Officer at Simpro Group, business software for trade professionals made up of three companies: Simpro, ClockShark, and AroFlo. He has worked in product management, engineering, and leadership roles in a range of industries, including mobile devices, data services, SaaS, and automotive IoT.

In our conversation, Jason talks about how, using his experience in private equity owner businesses, he runs the product organization with a return on investment (ROI) model — every decision needs to be evaluated against its potential ROI. He shares his experience aligning Simpro’s three businesses and going after the same market in each of them. Jason also talks about driving accountability and transparency by holding members to revenue targets, and how that ultimately brings everyone on board with the plan.

---

Making decisions for near-term impact

You have a very interesting background with some private equity experience. How does that impact your role and thinking as a CPO?

In my role as CPO, I have to have that private equity viewpoint of different companies at different stages. The biggest impact on that as a CPO is having to balance the short term with the long term. Private equity is not thinking 10 years down the road — depending on when they made their investment, they might be thinking three years down the road. So a lot of the decisions that I make need to have near-term impact, sometimes at a priority over making investments that could pay off in X years.

That’s why being cognizant of your owner’s investment thesis can have a big impact on your job as a chief product officer.

Has the structure of the product organization and general leadership varied a lot in your experience?

Different companies I’ve been at have done things in different ways. I’ve seen the CTO and CPO as peers. I’ve seen a CPO reporting to a CTO and I’ve seen it the other way around too. Mostly, they’re a function of the company history. It’s like who came in first and what was established. If you’re starting from scratch, you wouldn’t generally do that. You probably have them as peers, but sometimes as a company has grown, they start off with a CTO and they have product management reporting into a CTO. As the company grows, they realize they need to have more independent thinking on the product side to create healthy tension. They’ll pick off the product management piece from under the CTO and create a CPO role instead.

Bringing three companies together

Can you talk a little bit about K1’s three companies, Simpro, ClockShark, and AroFlo?

Our target customer is trade businesses. And one of the jobs that Simpro Group hired me to do is try to consolidate the businesses and the products since we’re all going after the same market space. Think of HVAC, electricians, plumbers, and those businesses providing services to residential or commercial buildings. Predominantly, our customers are on the commercial side, not the residential. Those trade businesses serve a whole range of industries — construction, security systems, video, traditional plumbing, gas, electric, all that sort of stuff.

They respond to three, what we call workflows, within trade businesses: service, maintenance, and project work. And that’s what Simpro does. It is better at certain things like project work and more comprehensive workflows. AroFlo does the same kind of thing, but for more simple workflows for smaller businesses for example. They compete in the same market for some areas, but it depends on the complexity that the customer is looking to solve. There’s some overlap. When K1 bought Simpro, they bought AroFlo not long after that because this provided the opportunity to own the two largest players in the Australia and New Zealand markets.

With ClockShark, they focus on employee time management — the amount of hours the employees spend on a job and how they get paid and how it is integrated into payroll. Trade customers buy our software and utilize a web interface in their office, and then their technical field staff use our mobile app on their phone.

Where do you start when you’re thinking about merging products?

The big question is, “Do we serve the same customers?” If you find that you’re serving a very different customer base in terms of size or complexity, then you have to change your product to be able to suit that. I worked for a company that got bought by HP and we were selling to consumers. When HP bought us, they said they wanted us to sell the product to enterprise customers. We basically had to re-architect the entire company. You can’t make that kind of transition easily. So the first thing to look at is your customer base.

The second thing to look at is the technology when you’re integrating companies. Are we all running on cloud or private hosting? What languages we’re using, is it well-structured, is it modular? In the case of these three companies, they are running in the cloud, but they’re all using very different technologies and they’re not modular. They’re all monolithic, and it’s just like a big ball of string. There’s no real way for me to integrate them on a technology basis.

Implementing a ‘get well’ program

You talked about how engineering reports to you, and so you’re weighing both sides — product and engineering. Are there any specific challenges to having that setup?

Engineering often concerns themselves a lot with technical debt, the level of investment they can put into burning it down, and bug fixing. They try to find time for tech innovation, but that can be a luxury in many companies. On the product management side, they want new features, new functionality, etc. And so you’re balancing that all each sprint cycle. You have new and existing customers that you have to please. But you can’t just look at it all from what you want for the customer, you have to consider the realities of the business as well. And I think that good product managers know how to balance that.

Sometimes you need what I call a “get well program.” You’ve got problems with the product and you say, “It’s unhealthy, there’s too much churn. We’d love to develop these new features and functionalities, but I’m going to have a get-well program. We’re going to focus on burning down bugs and some of the technical debt.” Sometimes, the get well program means I’m going to hire some contractors to fix underlying technical debt that can be broken off and fixed, or it might be that I move people around for a period of time to help burn this stuff down faster.

The other element of running both product management and engineering is communication. If there’s one voice, there’s no conflict. If you have a CTO and a CPO, and if they are speaking at odds, that creates confusion. It’s easier when there’s one voice and, for my boss, metaphorically, one throat to choke.

When everyone seems to want something different, how do you deal with prioritization?

If you search for prioritization on Google, there are so many different methods for it. What it all boils down to is return on investment. That comes back to private equity — who’s your owner? What are they looking for? If you can afford it, perhaps you can take a very long-term view on the roadmap, and place riskier bets and investments because your timeline’s much longer. Maybe you’re not going to be so maniacal about that. You might balance short-term need with some long-term risk plays. In my world today, I’m generally focused on a one-year timeframe. So my return on my investment is pretty short.

Next, what’s the potential reach to our existing customers or new customers? What’s the impact on our existing customers? The problem is, I’ve had product managers show me requirements and a certain feature is number 25 on the priority list. I will ask, “Why is it number 25? I would’ve thought that’d be much higher up than that.” They’d say that the impact isn’t great, referring to the impact on existing customers. I’m like, “Yeah, existing customers don’t care about that, but the market we’re trying to go after does. If we want growth, we have to invest in that.”

So what good a whole prioritization exercise if I just blew it apart just by asking one simple, subjective question? You could go through everything in somebody’s matrix and pick apart their prioritization. They can fall apart when you just change one number. Then, poof! Everything’s gone. All the assumptions that exist behind them can undo the model very quickly. And that’s a challenge. All these methods come down to some form of return on investment.

Holding people accountable

I understand that you have strategies for managing accountability. This kind of gets into sales-led vs. product-led organizations. Can you kind of talk about your school of thought around that?

We lean on engineering heavily to be accountable for hitting a date and hitting quality. The same responsibility should go onto the sales part of the organization saying, “You told us that if we had this feature and functionality, you would be able to get more customers. You told us if we fix this problem, fewer customers would leave us.”

We need to hold sales just as accountable for their requests. This comes back to the ROI model — the investment, that’s engineering, and the return is on sales. It can get hairy for sure. I just did this for 2024 planning. I looked at some of the roadmap items, just the top 10 with the largest investments, and went to each regional sales leader and asked, “How much revenue do you believe this is going to bring into the business?”

Whatever revenue they put down, that should be part of their target. Not because I’m their boss, but because I have to sit down with finance and talk about where we’re investing and the return on that investment. Then I find that everything comes back with small revenue numbers attached. So I’m like, “Okay, we’re going to cancel three of the things because there’s no return on that investment.” That gets pushback from sales, but I’m not trying to play a game. It’s about driving accountability and transparency. I highlight that this is the actual cost and here are the engineering resources needed. I believe it’s worth doing, but you’re telling me it’s not because these revenue numbers don’t reflect it. So as a business, what are we supposed to do?

When you have that discussion, there’s transparency. Once they get to a reasonable revenue number, they become bought in to the plan. They’re going to drive for those numbers and they’re going to drive the right behaviors in their organization to hit those numbers because they put their name on it.

How do you maintain that level of transparency throughout the year once targets are set?

You have to have monthly product alignment meetings with sales, marketing, engineering, and product managers. They’re the four key stakeholders. And you go through the roadmap and what’s changed. Having monthly product alignment meetings is critical because then sales is aware of what’s happening in the product, as well as any issues and limitations. And you can make them part of the solution.

And it goes the other way around — products and engineering need to hear from the salespeople because it’s unhealthy if product and engineering don’t spend enough time with customers. Whenever possible of course, product managers and engineers should join customer meetings, which can sometimes be uncomfortable for someone in product and engineering. But then they have an appreciation for the reality of how their products are being used. It’s where the rubber hits the road. Either way, internal, these alignment meetings are critical. Every month, you have to have them.

You mentioned the importance of spending time with customers. How are you talking to them and getting feedback?

We have a customer advisory board. We started that not long after I joined. For our top-tier customers, we have round tables with them. This year, we’re going to be doing a lot more customer outreach. Marketing has programs that they’re putting together to spend more time with our key customers and get their feedback. We’re doing a lot of surveys within our apps. For me, as I hear about customer issues, I’m asking to be invited to join discussions with customers. I’ve done a few of them already and the same customers have continued reaching out since.

A lot of support these days is impersonal. Talk to my chatbots, send me an email, etc. Once people find someone to talk to, especially at the C-level, and they are being listened to, they’re excited. We’ve got to remind ourselves that that is extremely valuable for that customer and you let them have what they need. Give them your availability. Unfortunately, you can’t do that for everyone. It doesn’t scale at all. But you’ve got to cherry-pick a few of them and jump in and say, “You’re my number one priority,” for however long it takes, and do your best.

Managing volatility in 2024

You spoke earlier about how you think in short-term, quick wins. What do you recommend for companies thinking about their feature requests and roadmaps in 2024?

Well, you could say there’s volatility in the economy. There are so many things going on. How do you plan for any of that when you’ve never been here before? I would say that you have to be prepared for the fact that your customer’s needs are going to change quickly because they may be responding to things in their own way. For me, I think I need to be a lot more flexible in my approach to prioritization and staying in tune with customer feedback.

I think you’ve got to have a great emphasis on staying totally in tune with what your customers are facing. As an organization, we may need to align things differently. Regular assessment and realignment. My recommendation to others and myself is to be prepared to shift your strategy, organization structure, where you put your resources, and then realign. Another aspect is uncertainty in decision-making. While I love being data-driven, when knowing where the assumptions are in your data and accounting for that, you might need to use more of your gut sense to manage risk and market volatility.

How do you see this volatility changing your approach to other areas of being a product leader, such as communication?

This year, I’m going to take things month by month. Normally, when it comes to resources, I would try to hire ahead of any pain. I think with this volatility, hiring has to be done after you’ve already started to feel the pain. And the more frequent communication, the better. This goes from the CEO down to every individual contributor. I’ll be over-communicating with the people at town halls, keeping everybody informed, and doing that monthly.

I expect changes in scenario planning as well. I spent yesterday working on a best-case and worst-case scenario. I think everyone has to do that for 2024 — planning for different outcomes and then having checkpoints. I call them lines in the sand because you might need to say, “I’ve got to draw a line in the sand, and by March, if I haven’t seen this, I’m going to have to take a different look.” You have to have these regular checkpoints with yourself and with your team.