Steve Shah is SVP of Product at Automation Anywhere, an intelligent automation solution. He started his career as a technical PM and Unix/Linux Kernel software engineer for multiple application delivery controllers and load-balancing companies. Steve then co-founded Asyncast, a mobile news service, before joining product leadership at Citrix. He is also a published author and wrote various systems administration books, including Linux Administration: A Beginner’s Guide.
In our conversation, Steve talks about the difference between product-market fit and problem-solution fit, including how problem-solution fit means taking the time to put yourself in the buyer’s shoes and understand what their life is like. He shares how his team explored and released AI capabilities to ease their users’ burden of needing to be proficient in code-writing. Steve also discusses his time at Citrix and how giving customers the option to use competitor’s solutions led to a more successful product.
My background hails from traditional engineering. I spent the ’90s doing a lot of hands-on IT work, and it was great to get that perspective from a customer. That led me to write a series of books on Unix and Linux, which was an interesting step that I didn’t expect to take. In the 2000s, I transitioned more into product management. I was in a startup and talked with sales a lot because I could explain what the technology did and its value to customers. I could frame it in terms that they really appreciated. The head of marketing came to me and offered me a PM job, and I took it.
In the back half of the 2000s, I created my own startup. Pro tip: if you’re ever going to do a startup, don’t do it during an economic meltdown. I learned a lot through that experience, such as where my personal gaps were. That’s a great thing for early-career product managers to do — take an honest self-assessment and be open to that feedback.
I joined Citrix Systems back in 2010 because one of the startups I worked with previously had been acquired by them. I was working with that same group again but in a slightly different role. That began my transition toward being far more business-oriented as opposed to tech-oriented. I was the VP of product for Citrix’s networking group, and in 2018, I recognized a big gap in my own career: I had heavily leaned toward selling to a CIO, but I didn’t have a lot of experience selling to the line of business. That’s when I joined Automation Anywhere.
It has been multiple jobs in one. Early on, it was very focused on building up the company. I joined when they were still pretty small and from there, I got to build a team from scratch. We went from four people to 30. In product management, we had gone and taken a platform that had not gotten a material facelift in seven years and re-platformed it. We had a business that had no operational structure in place, so we added those frameworks and structures. Partnering closely with my counterparts on those other teams was an exciting experience.
The second phase of the company — that started about two years ago — was going through that maturity step of saying, “Now that we’re at this certain size, how do we go and accelerate it and move to the next level?” One of those big transitions was embracing artificial intelligence as a big part of our go-forward planning. And as we’ve learned with generative AI, it’s important to do that within the edges of good governance. The user of our product likely doesn’t eat, sleep, and dream in code. They use our product, but they’re not waking up every day excited about technology. That leaves us to figure out what their experience needs to look like and what makes them successful.
There’s a big difference between a problem-solution fit versus a product-market fit. A problem-solution fit is taking the time to get yourself in the buyer’s shoes and understand what their life is like. If you are building products to solve their problems, you’re on the right track.
Early in your career, you think, “I’ve got a cool widget, everyone needs this cool widget!” But who’s going to buy this thing and why do they want to buy it? If you can’t clearly answer those questions — and “because it’s cool” is not a valid answer — you solved a problem no one was asking you to solve. The distinction between a problem-solution fit versus a product-market fit is important.
One of our customers is a South American petroleum company. The person who was most interested in our product was from the finance side — specifically the tax team. We needed to frame the conversation for that use case. If you didn’t talk about how you were going to help him do taxes, he was not interested. When we pointed out generative AI could read all of the new tax code changes that were coming out and give him summaries, he was all like, “Wow, we literally spend months doing that. If you can give me a clear summary of what has changed and let me build a couple of automations just to streamline those processes, that would save me a ton of time.”
It turned out we hit a particularly great vein because it saved them a ton of money. They reduced their tax burden by $120 million.
The problem space that we were dealing with empowered our developers to be more effective at building automation. A lot of the people who are building automation are not software engineers, so we started exploring generative AI as a vehicle for easing some of that burden of needing to become experts in writing code. Automation Co-Pilot was a couple of big generative AI capabilities rolled into one bucket for developers, and we definitely hit a nerve there.
The first big thing was being able to just type in an English prompt and get some code out. This is a lot like GitHub Copilot, except we differ from them in the kind of scripts that our Automation platform uses. We use a drag-and-drop tool for building automations, so you don’t actually type in commands. We needed generative AI to build these flows that didn’t have billions of examples of Java code.
The second capability was helping somebody who already had an existing automation figure out what their next step was. That made it easy for somebody who may not be a development expert but perhaps adopted somebody else’s automation. We also address a really interesting challenge of automation software in general, which is letting you record what your clicks and typing do so you can replicate it later. Now, somebody who has automation-building skills can take that recording, generalize it, and repeat the task over and over again. The vast majority of our customers do this for a wide range of applications.
The last piece of this is the same idea, except our source is a recording of a full end-to-end business process. If I’m trying to do something big and complicated that’s made up of multiple individual tasks, how do I make that into an automation? We’re able to do that. GenAI can make these highly localized decisions for us that don’t take real brain power, but they suck up a lot of time. We’re freeing up devs because they’d rather build new automations than go back and fix old ones. This is a way that you can do that.
We, as an organization, were recognizing that all the major cloud providers were coming into our space and providing those same tools. Increasingly, our customers did not want to buy hardware. That was clear. We needed to figure out what our software strategy was, and this was one of those moments where being honest with your customers and knowing when to just listen became really key.
There was a specific meeting that we had gone to for the specific purpose of pitching to a select audience. These folks represented the biggest .com sites in the world, their buying authority was ridiculous. I was on slide one and their faces were clear as daylight — their eyes were glazed over. Sometimes, being able to see body language helps. I shut my laptop, grabbed my notebook, and I said, “What am I not getting?” We use that hour just to collect feedback from them.
The insight we received was super valuable. They told us they were already adopting containerization and had two main problems: managing all of these containers and being responsible for failover. With those two insights in mind, as we started talking to different customers about the same thing, we said, “Look, we’re having an honest talk. We’re not here to sell you things. In fact, I’m here to get rid of selling you things.”
The enterprise players we were talking to said, “Look, I’ve got the same problem with being able to go and hand over data to a different data center, but in my case, it’s going to the cloud. I need to be able to swing some of it back because I’m not 100 percent sure about this whole cloud thing.” They had a ton of tech that wasn’t compatible but was running critical parts of their infrastructure. Being able to go and move back and forth was a key thing, and that changed our whole perspective.
Rather than looking at how we go and make the network faster — because that was the nature of our hardware products — we realized that the conversation was far more about how to cope with managing through this transition. The product we put forward in that was a management and analytic system, and that was its function. It lets you go and track thousands of these little instances.
We took a bit of a bold step there and we said, “You know what? We’re going to transfer work to our competitors and we’re going to be OK with that.” The idea was that this is like a bank that only takes deposits. If you only take deposits, at some point, people get nervous about giving you money. You have to be willing to transfer out to a different bank, and in this case, we were willing to transfer work to AWS. But vice versa, they wanted to be able to go and take work back from AWS and move it back into their own environment. We supported those capabilities too and we started supporting third-party load balancers of the networking piece.
That freedom really led a lot of companies to embrace the technology and start looking at us as an alternative to our number one competitor. That was an eye-opening experience. Being that open, letting people move away from you, and giving them that trust invariably leads to more trust. That was a good wake-up call for us. The business reacted very well to that.
You have to put yourself in the other person’s shoes and ask, “What’s going to make this person successful?” What may make them successful may not be embracing some new technology, it may be doing right by their team and their company. Putting yourself through that perspective and making sure that you’re clear on that is key. Increasingly, you don’t have to share a background with that person. I don’t have a finance or healthcare background. Sitting down, listening and paying attention to what they have to say, and trying to internalize where their angst is will take you a long way.
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?
Act fast or play it safe? Product managers face this daily. Here’s a smarter way to balance risk, speed, and responsibility.
Emmett Ryan shares how introducing agile processes at C.H. Robinson improved accuracy of project estimations and overall qualitative feedback.
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.
Learn more →
