How I went from Sales to Product Lead to Founder
Matt Hinds
Background
Currently, I lead a software company that I co-founded 1.8 years ago called Sauce AI. We’re building the leading AI customer insights tool for product and customer-facing teams. For the first stage of our journey from zero-to-one I was focused on building our product, now I’m leading our go-to-market.
Sauce AI
But my relevant experience for this conversation is at a scaleup called SafetyCulture, the operations platform for frontline teams. I initially led their flagship product team, Inspections (a digital inspections app), then moved to lead the launch of one of their newer products, Issues (an incident reporting app), to help grow the business.
I learned how the product management role changes as you work on products at different stages. Inspections was a mature product, having been around for almost 10 years. This meant it had lots of data, feature requests, documentation for customers and enablement for go-to-market teams, so the roadmap was clear and it wasn’t hard to enable teams to sell the product effectively.
The main challenge was stakeholder management - because the flagship product accounted for >90% of SafetyCulture’s platform usage and revenue, this meant that sales, success, support and marketing teams relied on it to hit their targets. So a lot of my time as a product manager was fielding their requests (features, issues, support cases, sales deals, etc), trying to understand patterns and the root cause behind them, and deciding whether to prioritise them. This often meant time spent seeking more data, aligning stakeholders on where their request fit into the bigger picture, and more often than not, saying “no”.
Our Issues product at SafetyCulture
Since Issues was a new product, we needed to first form a solid product vision and strategy. We did this by:
Interviewing 50+ customers to understand:
How do you capture and report on incidents today?
Where are the biggest problems in this workflow?
What are the consequences of these problems?
Which KPIs are impacted?
Who else cares about incidents and these KPIs?
Doing a lot of market research to understand regulatory frameworks (safety compliance space), speaking with subject-matter experts and understanding the competitive landscape
Looking at new technologies to understand how they could solve customer problems faster, cheaper and better
Partnering with internal stakeholders (leadership, GTM teams) to get their perspective on the customer problems, where this product fit into the broader company strategy
One of the biggest jobs beyond defining the product vision and strategy was aligning stakeholders across the business, particularly the go-to-market teams. We started with focus groups to understand:
How were they selling the product?
How did they describe it to customers?
Where were they receiving the biggest customer objections?
Why were we losing deals?
If they were the product manager, what are the biggest problems they’d solve next?
We then categorised this data to understand patterns and trends, to then inform the features we’d build, documentation we’d create to enable them to handle objections better, case studies to inspire them… essentially the key initiatives that helped grow the impact of the Issues product.
Other than building products at SafetyCulture, I did a Commerce degree at Sydney Uni so I had a finance background, spend a year in B2B Sales at Amazon Web Services, but the most relevant experience I had in product was building my own startups (more on that later).
Presenting Issues product vision and strategy at SafetyCulture’s ‘All Hands’
How my prior professional experience affected my transition
One of my biggest fears in the early days was working with engineers. I didn't come from a technical background and there was this ongoing debate about whether you needed to be technical or not to be a PM. In fact, when I interviewed with SafetyCulture their first question was, “tell me about your experience working with engineers in the past.” Whilst I’d worked with engineers in building AgCrowd, I hadn’t been an engineer myself.
After a while, I learned that whilst it’s important to be able to understand how engineers think and be able to communicate/motivate, you don’t need to be deep in the technical weeds with them (depending on how technical your product is). Product is broad, and so rather than trying to be the jack of all trades, I focused on being the master of one. My advantage was on the go-to-market side.
Because I'd come from AWS and I had been in sales and success, I knew how that part of the business worked, what motivated them, what their KPIs were, etc. That meant when I jumped into SafetyCulture, I could quickly build relationships with go-to-market teams, empathise with the things they cared about, learn where they're losing deals, and where customers are objecting, and use that as a core lever to increase whatever their KPIs were.
PM can be quite broad so you can shape into whatever will help you drive the most product impact, the fastest. As a broad example, if you’re a lawyer, you can use your negotiation skills and attention to detail to rally teams and find the best outcomes when managing stakeholders.
“Product is broad, so rather than trying to be the jack-of-all-trades, I focused on being the master of one”
The kinds of qualities/experiences you might have that I think can help you excel as a product manager are:
Communication - can you work through problems, understand people's needs, and align people quickly?
Leadership - can you influence your engineers, go-to-market teams and leadership to run fast in a certain direction?
Data-based decision making - can you understand data to figure out what the opportunities are and which your team should invest in?
These are just a few examples that first come to mind. When you’re thinking about how your past experiences can help you become a great PM, always take an impact-focused approach. That’s what PM is all about. How did X experience help you move a metric from Y to Z? This will show others that you think like a PM.
But really the best preparation for Product was the startup I founded. Going through the motions of identifying a problem, figuring out the initial solution, mapping your acquisition strategy, and running experiments… prepares you for most of the work you do in product.
How I planned and executed my transition from Sales
I obsessed over learning the Product craft. After I finished up at AgCrowd, I did a $10 Udemy course where I picked up all the Product terms and buzz words; what’s a product strategy, prioritisation, quarterly planning… those kinds of things.
But the main thing I did was talk to people. I found friends and people on LinkedIn who were PMs at various companies like Atlassian, Canva, Domain and reached out to them. Some replied, and I’d jump on calls and ask them a ton of questions - they turned into mentors. I would do mock interviews, ask for tips on how to do PM case studies, and how to stand out against other PMs.
“It only requires some extra effort to go above and beyond other candidates”
Beyond this, there were two tactics that helped me stand out during my PM interviews.
First, go and find public feedback for the company you’re interviewing for - you can find this in App Store / Play Store reviews, Capterra, G2 and more. Download the feedback, analyse it and identify key patterns/themes. Summarise this into a problem that an ‘X’ amount of customers are facing. Then research the market to understand trends and competitors, and form a hypothesis around how you could solve it - doesn’t need to be perfect, all that matters is the thought process you went through. You can then share this during your interview - turns out people hardly go to this effort, so it’s pretty easy to stand out.
Second, you’ll usually do a case study interview as a PM. You’ll hypothetically be the PM of a product. For example, during my SafetyCulture interview, I was the PM for Slack Notifications. They gave me a bunch of features to prioritise and I had to present back a roadmap and ‘why’ I’d prioritised the way I did. So I went and interviewed 20 friends who used Slack to get actual customer feedback/data to prioritise. Turns out the interviewers were blown away that I’d actually interviewed people and gathered real feedback. It only requires some extra effort to go above and beyond other candidates.
Advice
One of the biggest mistakes I see PMs do is looking at their product in a silo. Instead of thinking that your job is to build features and others should sell them, it’s important to zoom out and get an understanding of the full product lifecycle.
Why does your product exist?
How does it contribute to the broader product strategy?
Who’s involved in building, marketing and selling your product?
At what point in their journey do customers first discover your product?
Is your product's purpose to grow revenue, usage, or something else?
Only then can you start to really understand the levers you can pull to make the most impact. You’ll learn how you can bring each business function along on the journey and embed them in the day-to-day so they can be most effective, rather than throwing features over the fence to them when they’re finished and treating them as consultants.
So I’d start by mapping out the different teams who are involved in your product lifecycle, then go and meet with them. Ask them questions like:
What does your day-to-day look like?
What are your KPIs?
Who do you collaborate with?
How can I make your job easier?
For example, you’ll meet marketers who are responsible for generating leads, people who are responsible for helping new users find value quickly during onboarding, success teams responsible for growing larger managed accounts, and the list goes on. All of these people can help you grow your product - so understanding which parts of the lifecycle they influence is important.
Beyond that, my biggest advice is to figure out what your ‘advantage’ is, then lean into that. I first tried to learn Python as a side hobby to see if I could be stronger on the engineering side, but this wasn’t my thing. I realised through my experiences that I understood go-to-market, particularly marketing and sales better than other PMs, so I leant into this. I built great relationships with go-to-market teams and helped them grow revenue which in turn grew my product.
Finally, it’s worth being intentional about the type of organisation you want to work for. For example:
Startup: if you’re the first PM at a startup, it’s generally going to be pretty chaotic. I love this because you can have an enormous impact, and there’s not many people or processes that can slow you down, but others who prefer structure and certainty may not thrive in this environment
Scaleup: you’ll get a mix of some structure and process and some uncertainty. You’ll have a huge opportunity to grow since there will be lots of problems to solve and new opportunities for the business to invest into
Enterprise: you’ll likely have access to lots of data and lots of great later-stage product people to mentor you. You may have less impact and independence, but for people who like more structure, you’ll likely enjoy this environment more!
Why I chose Product Management
I started my career building startups. First co-founded an ecommerce business called Noggans, which designed, manufactured and sold clothing products.
Noggans shipments arriving at immigration and packaging for customers
Noggans stalls at Splendour in the Grass and Lost Paradise music festivals
Then I co-founded a FinTech startup called AgCrowd, an investment marketplace which required a software product to be built. This threw me in the deep end - when I first started I had no idea what I was doing. We outsourced development to an engineering team in Sri Lanka, with a tech lead and eight developers and I was basically the product manager at the time, even though I didn’t know what a PM was until a year or so later.
Agcrowd’s investment marketplace product
“Everything you’re doing right now as a founder is basically what a Product Manager does inside of a larger company”
We sold the FinTech startup a couple of years later and during that period I was figuring out what to do next. I caught up with my friend James, who was a PM at Atlassian at the time and is now my co-founder at Sauce AI. After explaining that I didn’t want to pigeonhole myself into a role, but instead be involved in different functions across the full product lifecycle, he said, “everything you’re doing right now as a founder is basically what a Product Manager does inside of a larger company.”
This was a lightbulb moment for me, and from that moment onwards I started obsessing over getting into Product. I also knew I wanted to build a software startup again, and I realised that I needed to level up my product craft, so mastering that art before jumping in again seemed like a great next step. So that was why I first directed myself towards product management roles.
Since working in Product, I’ve realised that the day-to-day work can vary wildly depending on the type of product you’re owning and the stage that product is at. As explained, on more mature products there’s tons of data, lots of stakeholder management and a really clear roadmap. In contrast, earlier-stage products are all about taking a lot of bets with faster iteration cycles. You’re constantly developing a hypothesis, testing it with new features or experiments, getting feedback and learning quickly, then adjusting your hypothesis as you make your next bet.
When you’re building a new product - the first time you get it in front of customers' hands you’re almost always wrong. The aim is to learn to what degree you’re wrong, then rapidly learn and iterate until you’re ultimately right. We call this finding “product-market fit”.
There’s also a big difference between working on B2B vs. B2C products. In B2C you’re building for individual consumers, like you and me. Whereas in B2B you have a buyer (the decision maker), usually a manager or executive who owns the budget, and a user (usually an individual contributor employee) who uses the product to do their job. This influences how you prioritise features - in B2B, you may have to build things which please the buyer to get the deal over the line (e.g. SSO/SAML) which the user doesn’t care about, and vice-versa. It’s a constant balance.
Also, in a B2B setting, you're angling yourself to get a share of your customer's budget. From a budget perspective, it’s often easier to replace an existing tool because then the buyer can reallocate that budget towards your tool than it is to create a new software category which doesn’t have any existing budget towards it. But on the flipside, if you’re replacing a tool that means there’s already a “bar” set for the quality and function of the product. Your job as the PM is to figure out what that bar is, where the product falls down, and then at a minimum, your product has to at least meet (if you want to be competitive) and then exceed the bar (if you want to win).
B2B teams rely on a mix of qualitative and quantitative feedback. Whereas B2C teams can often be more quantitative / experimentation-driven. If you look at companies like Uber or Duolingo, they’re constantly running experiments and A/B tests in their products, analysing results and making product decisions based on that.
Personally, I’ve had more experience in the B2B software landscape. To me, it feels more logical in what you’re building and why you’re building it. Businesses are always evolving with the market and new technologies, and as a result, there are always more problems to solve.
AgCrowd investor event “The Future of Investing in Agriculture”
What's next with PM experience
My current focus is on scaling Sauce AI, the product management software startup I’ve co-founded. We identified a number of critical problems in how teams understand their customer.
First, product teams typically rely on a number of feedback channels to build their understanding of the customer's needs. For example, support teams, sales teams, marketing teams and the customers themselves. Often these channels are fragmented across different tools and parts of the business, but even then they’re consolidated into a single place, it’s incredibly manual for teams to review the feedback, decide who’s team is responsible for it, and then categorise it into actionable trends.
This makes it incredibly challenging for product teams to understand and keep up-to-date with what customers need and impacts the customer-facing teams who report the feedback because it’s often linked to deals they need to close or support cases they need to solve.
So Sauce AI is consolidating these disparate feedback sources into a single place, automating actionable insights in real-time (so there’s no manual effort), and democratising these insights so every team is instantly aligned on the top customer needs.
If you’ve made it this far, thanks so much for reading! Feel free to connect or message me over LinkedIn: https://www.linkedin.com/in/hindsmatt/
