Leader Spotlight: Learning outside your walls, with Fielder Hiss

---

Fielder Hiss is Chief Product Officer at aPriori Technologies, a leading cloud-based platform for the manufacturing industry. Before joining aPriori, Fielder worked at several technology companies focusing on both hardware and software products, including SolidWorks, Continuum, and LiveAction.

In our conversation, Fielder discusses the process and challenges of bringing on-prem products to the cloud, including changing requirements in customer expectations around things like security. He also shares the nuances of the product management process when building both on-prem and cloud products, such as security, a more iterative roadmap, and increased internal communication. In addition, Fielder talks about how “learning outside of your walls” is key to identifying patterns for product opportunities or improvements.

---

Combatting incrementalism

You have experience that spans multiple sectors. How have the challenges and learnings across these sectors shaped your approach toward product management?

I’ve worked in manufacturing software, energy management software for large enterprises, IT, and cybersecurity as well. I don’t feel like each sector necessarily has a unique approach to product management. I think they’re consistent in focusing on how to identify key problems for your target customer.

A big thing that does vary by industry is the size of the customer. That affects their willingness to configure or customize things rather than use your software out of the box.

There are also different regulatory requirements that may influence things depending on what sector you’re in. This is not necessarily privacy and information regulatory requirements, but regulatory requirements that may be challenging for both businesses and utilities to solve. If we could find unique ways to attach to those problems, there’s already a budget, concern, and executive awareness about the regulatory frameworks that they operate in.

When we spoke offline, you described your job as making the addressable market larger for the dollars spent in R&D. Could you talk a little bit about that?

Over my experience, I’ve begun to really say that the fundamental job of product management and product strategy is to look at the company’s position, where the core competencies are, where they’re solving problems, and then find out how we can address new industries with the same core technology. Can we solve different problems inside of the same industry? Can we get different personas to begin to benefit and use the technology?

Ultimately, if I can not only access and address more of that total addressable market but broaden it, it’s a numbers game at the end of the day. If you can really begin to change who you’re selling to, the industries you’re selling to, and the solutions that you’re selling, you’re making your potential share of the wallet much larger.

I use that as a leadership tool to combat incrementalism. You can always add another feature or an extension of another feature, but it’s not necessarily demonstrable. This is where I think product managers can get stuck.

Moving products from on-prem to the cloud

You also have extensive experience transitioning companies from on-prem to SaaS. How do you ensure that the value proposition of transitioning to a SaaS model is clearly communicated and understood across different stakeholders?

Many companies have gone through this transformation now, but one of the biggest challenges is that, in an on-premise software world, you typically recover your cost of customer acquisition times two in an initial deal. The best high-performing SaaS companies are covering the cost of customer acquisition in the B2B space in roughly 12 months. They call it the time to recover.

That’s a fundamental challenge and is a big change for a company. You no longer think about bookings in just revenue, you think about MRR and ARR. That economic transition is very different. Now, they build much more long-term value. SaaS is much stickier. You have higher retention rates and things like that. People want that flexibility — a lower cost of technology acquisition on the customer side as opposed to a large upfront smaller maintenance percentage.

With respect to product management, there’s a mindset where if the internet works, everything else is your fault as the vendor. No longer are things hosted on dedicated infrastructure inside of the customer’s firewall or on desktop computers. And we own the rest of the experience. There’s a lot more that goes into a mindset on software service, particularly regarding owning the experience, the performance, and very importantly, the security of the solution.

That introduces new requirements and new thinking that is paramount in the SaaS industry but is not true at the same level on-premise. If the application is at rest, it’s encrypted and it’s secure. The rest is inside of the customer’s firewall, so the security is their problem. With cloud security, a vast majority of security is my problem as the vendor. You’re more accountable for a lot of the experience.

I would think it’s about the investment too, right? On the business side, it must be a bigger investment to ensure that security is buttoned up?

Yes, there are audits and certifications. There’s a lot more expectation and responsibility.

A lot of things have changed because of that. The good news is that more and more organizations are comfortable with software as a service. They know the questions they want to ask of you as a vendor, but you have to be prepared to answer them to win someone’s business.

Besides thinking about the security component, are there other things within product management that are different? For example, the way you think about customer loyalty or changing the roadmap?

The roadmap is much more iterative. Obviously, you have your anchors in a longer-term roadmap, but the great thing about SaaS is that you own the updates. You’re continuously deploying new capabilities. You have that ability, that flexibility to continuously deploy new capabilities whereas, on-premise, it’s up to the customer when they upgrade. They often don’t want upgrades more than once a year. A customer could be on multiple versions back, but in the cloud, there’s one version.

We’re also able to deliver value more regularly. We’re averaging one release per week of new capabilities, and there are other folks doing one release a day, particularly on the B2C side. That’s exciting, but that leads to a much more agile planning process. Regarding the roadmap, we have a lot of focus and clarity on the next 90 days, but six or eight months out, it can get fuzzy on exactly how we’re going to do it.

Do you find that it requires more collaboration internally with other departments?

It definitely requires more communication. We have different stakeholder structures than we’ve had in the past. We have stakeholders from customer success or our application engineering team who are involved in some of our more regular discussions. On top of that, we also have to communicate more frequently with what and when things are coming, because things change.

It definitely has its own unique challenges, but it has its own benefits as well. There’s more collaboration on solutions, using an agile development process and engaging more. We focus less on big product specifications and requirements and more on the problem we’re trying to solve, key capabilities, and how to work together to come up with a solution.

What about how you measure your outcomes or your successes and KPIs? Is that different as well?

It’s nice because once you’re in a SaaS world, you understand so much more about usage. There was usage in on-premise software, but it’s opt-in. Much like with your Microsoft operating system, you opt into sending them reports, but we know exactly who’s using it, how many daily, weekly, and monthly active users we have, etc. Those are key KPIs for us.

Obviously, we have sales targets. Then, once customers buy, how’s our adoption? We look at the percentage of adoption and try to understand that. Then, we can do that at a functional area and even down to a feature level. Some organizations go very heavily at feature-level usage metrics, but I feel like it’s not the most important thing. For me, it’s at the application level and understanding those insights. With usage and adoption metrics, you can get leading indicators proactively about “unhealthy” accounts.

These become very key KPIs for a company. Then there’s also financial KPIs that are important as well, like time to recover the cost of customer acquisition or CLV. You can look a lot at customers growing. Traditionally, in an on-premise world, you look a lot at gross customer retention. In SaaS, we want 115 percent or so net customer retention, which means a customer’s growing, on average, by 15 percent when you take the whole cohort together.

Identifying and pursuing opportunities for innovation

A key part of your role is evaluating complex scenarios. What’s your approach for really examining the data to look for patterns and potential opportunities?

Particularly in the product area, we try to identify areas that we see as opportunities for investment and then go out and talk to people about the challenges they’re having in those areas. Part of that — learning outside of your walls — is a key foundation for identifying patterns, and a lot of things start conversationally.

For example, when I was at a company called Continuum, we had a business where we delivered IT solutions to managed service providers who managed IT for small and medium businesses. We knew there was an opportunity here to help them with the growing cybersecurity challenge. We found that the biggest challenge for managed service providers was not a gap in an endpoint protection solution or a firewall — it was that they had all these point solutions but couldn’t see the gaps where the water would leak in.

They were amalgamating together a bunch of point solutions from different vendors without a control panel view or a view of health for their customers. We were able to give them that view of health and then give them the view of the most vulnerable areas of their population so they can focus their energy to mitigate or remediate those areas. You start to see a picture and then you can piece that into an opportunity.

And when you’re finding opportunities, would you say there’s a specific ratio for pursuing innovation versus adding new features to solve an issue?

That’s always tricky. It depends on the state of where you are and your growth as a company.

We use hard percentages for development allocation and certain things, but that’s inclusive of customer issues and support, infrastructure, technical debt, and new capabilities. We do use a framework, for example, to do that allocation, but I’ve never seen a set way to think about it.

The thing that we try to do is look for the bigger problems, newer problems, and then back into what it would be worth to a customer to market if we were able to solve that problem. Does it create a material area of growth for us that is worth investing in? That’s different for every single company.

For example, if you’re a $100 million-dollar company, something that only opens up $10 million dollars in a new total market is not interesting, whereas something that opens up $50 million dollars is. It gets to low numbers, but if you’re, say, a $5 million dollar company and you identify a problem that’s another $5–10 million dollars, that’s very material. You can get a few million of that and really drive complementary or accelerated growth beyond the current state.

I think it all gets to where you are in your current market, how much of it you’ve addressed, and how big you are. Then, unfortunately, when you’re a $500 million company, if it’s not a $100 million dollar idea, it’s often not worth pursuing.

Enabling teams to thrive

Finally, you mentioned leadership earlier. Could you talk about your approach to building and sustaining high-performing teams?

The first thing that comes from high-performing teams is really pushing authority and decision-making down as far as possible. If I’m making a majority of decisions, there’s a problem. There’s setting the strategy, that’s one thing. But then there’s the delivery of the strategy. People will thrive and surprise you the more you push things down.

The second thing is creating accountability for the organization, its problems, and its challenges, as well as the individual’s problems and challenges. It’s important that when people bring a challenge to you, you don’t take that problem and make it your problem to solve. I tell my team that they can bring any challenge, but bring a solution with it. What I mean by that is if you see something, say something — to borrow a phrase from the TSA — but not everything needs to be addressed.

I’ve found that if I ask them to think through the problem and how they would solve it, being forced to do that helps them solve it. That’s better than people coming to you with a problem and asking you to figure it out. And if a solution isn’t found, at least that effort’s been made and you can help them get to the best solution. I always say that there’s often no right solution, but a best solution.

From building teams, you need to have people that you trust. The last big thing that’s really important is utter transparency with your teams — always letting people know where you stand, where they stand, and providing honest feedback at all times. If you’re doing an annual review, with an employee, for example, if they’re ever surprised in that conversation, I failed, not them.