Product used to be a physical object you sold, like a book or CD. Today it’s a catchall term for how your business delivers value. ChatGPT is a product. SaaS is a product. Even an agency’s services can be “productized”, divided into packages and sold online like Ikea furniture.
As a result, you’ll find most online businesses employ product teams to discover and deliver new customer value. Living at the intersection of business, technology, and user experience, product teams draw from each to build features, flows, and upgrades that customers love.
Does that mean building everything customers ask for? Well, no, you can only do so much with the time and resources available. Determining what to build involves researching customer problems, brainstorming solutions, and then validating only the most promising.
In this blog, I’ll try to unpack what product means to me and the team at Acquire.com, and maybe you’ll find a lesson or two you can apply to your own business. But first, let me tell you a bit about how I became the product guy at Acquire.com. It’s been a wild ride so far!
How I Became the Product Guy
You might know me from the product-update emails I send when we ship a big release. I sign those as VP Product at Acquire.com, but it’s been a long road to get here.
I studied business management in college. Back then, product management wasn’t part of the curriculum, and the term had yet to become part of the business lexicon. If you’d have asked me what product discovery, sprints, or OKRs were – terms I use regularly today – I’d have shrugged my shoulders. The role of “product manager” was a mystery to me. An unknown.
But that would change when my college buddy and future founder of Acquire.com, Andrew Gazdecki, started a little business called Bizness Apps.
Andrew Gazdecki and I go way back. We were in the same fraternity at Chico State, ambitious kids who loved talking about entrepreneurship. We’d spend hours discussing his business ideas, and one day, Andrew asked me, “Do you want to help me design mobile apps?”
I said yes, and my first experience of designing products followed. On Photoshop. Without any experience. I didn’t know Bizness Apps would be acquired in a multimillion-dollar deal less than a decade later, but that’s another story. For now, I was an intern at my buddy’s company, having fun in Photoshop between classes, and not thinking too hard about the future.
Bizness Apps had a simple goal: to make it easy and affordable to build mobile applications using our custom app builder. We were pioneers in 2007, but it was all manual. We’d design app skins in Photoshop (just images) and import them to the app builder. Then we’d upload the finished apps to the App Store. It was as simple and laborious as it sounds. But it worked.
Andrew has always been a get-stuff-done kinda guy. If a customer asked for a feature, he’d want to build it, and my job was to step in and manage that process. But I wasn’t researching customer problems so much as shipping the best of their requests. That was my understanding of product management back then. I wore many hats at the company, switching from app fulfillment to operations to product support and finally head of product.
Riding the high of the acquisition years later, I landed a product role at another startup, and I was anxious to make a good impression. I wasn’t working with old college buddies anymore, and I couldn’t rely exclusively on what I’d learned so far.
I began reading books and listening to podcasts, trying to redefine product management so I’d succeed wherever I chose to work.
Defining Moments
You probably know a little more about product management than you think.
Just dealing with the everyday issues – the support tickets and customer inquiries – reveals what you’re doing right and wrong. You don’t need to carry the product manager title to shape your company’s product. Everyone in your organization plays a part (including customers).
For example, one of the earliest things you learn as a product manager is not to rely too much on outside parties. It’s usually better to build something in-house if time and resources allow.
I remember one of our technology partners at Bizness Apps increased its prices five-fold, forcing us to build an equivalent solution in-house. We’d used their software to livestream the app-building experience (native iOS app simulators didn’t exist back then).
David Morton, our CTO at Bizness Apps (and the future CTO of Acquire.com), led the project to build our own livestreaming technology. I can barely write a line of code, but just being involved in product design taught me how to think about engineering problems.
Another issue at Bizness Apps was having to manually upload apps to the App Store. Automation tools didn’t exist in those early years, so we’d been forced to hire a team to upload apps manually. Not the most interesting work, or the best use of our people, but it bought us time to design and build an automated process that transformed our business.
My next company, Rubbl, was a multi-sided marketplace like Acquire.com but for heavy construction equipment. The challenge was estimating prices and routing trucks. The height, weight, and width of the machines influenced the roads, bridges, and highways they could travel on. Weather and road works could also hinder deliveries. In the end, our talented engineers built a machine-learning algorithm to estimate the transportation costs for us.
At Rubbl, I also learned how hardware, software, and service can combine to create serious customer value. For example, we fitted GPS units to every machine, and when they came in for service, associated them to the machine via the inspection app, and then we could geofence different stages of the delivery journey. Customers then knew exactly when their machine left the yard, was nearby, and had arrived.
Bizness Apps and Rubbl each presented unique product challenges. It was a fantastic journey getting here to Acquire.com, and I’ve applied many of my previous learnings to building the acquisition marketplace you use today.
Product Principles
If you always try to perfect your product, you’ll never launch it.
First, build something functional. It might only do one thing. For example, Acquire.com only connected buyers and sellers in its first few months. Andrew vetted all the listings and buyers himself. Only when we knew what the problems were did we use the product to solve them.
Iterative product development is just one of many principles we follow at Acquire.com because we know it works. You can build a better product once someone has shared their likes and dislikes. The more people test, the more you know what to change or fix.
Balance Speed and Rigor
The faster you ship a product or feature, the quicker you get valuable feedback, but that doesn’t mean you can ship broken or dysfunctional software. Equally, you want to be rigorous in our research, but not so rigorous you’re perfecting something users have yet to test, potentially wasting time on things that you believe matter but the end user doesn’t care about. Finding that balance between speed and rigor is the starting point for any product sprint.
Another component is balancing the amount of risks you tackle upfront versus after you ship. Collecting evidence takes time, whether you’re looking at data analytics, interviewing customers, or conducting a usability test with clickable prototypes. You can collect some evidence before building, but nothing beats post-launch feedback. It’s up to you to decide when to switch from one to the other – just be ready for potential fallout.
Focus on Needs and Problems
You might be tempted to fix a problem the moment you hear about it. Being too reactive, however, can result in some unexpected (and unwanted) consequences. For example, there are usually multiple solutions to a problem. The easy solution, the hard, complex, slow, or cheap, and so on. You won’t know which one is best until you’ve explored the problem in detail.
Discussing product development with my team, we often call out solution-thinking to refocus us on the problem. It’s a natural human tendency to dwell on the solution and skip over what’s causing the problem. Instead, analyze the underlying problem and formulate solutions as a team before picking one with the best impact-effort-value ratio.
Think Holistically
I love shipping new features, but even I have to watch for tunnel vision worsening my biases. Before releasing a new feature, consider how it fits into the broader customer experience. How will it affect the customer lifecycle? Will it slow things down or speed them up? Will it make something easier or harder? Whose roles will it affect? For example, if a new feature pushes waves of customers through the pipeline, can your infrastructure and salespeople cope? Can you maintain standards?
Think of releasing a new feature as introducing a new species into an ecosystem. You might expect the ecosystem to flourish, but any change in your product will ripple across the business and might have unintended consequences. It’s your job to prepare for them.
Discover to Innovate
Innovation seldom starts with a lightbulb moment or randomly assigning some framework or theory to your product’s design. Only by discovery techniques can you truly develop a product that people want with the resources available to you. We have a lean startup mindset and leverage design thinking to create an empathetic user experience. Discovery means thinking like customers, exploring what they might want to do, their blockers and accelerants, and so on, and then innovating based on what we’ve discovered.
Collaborate Across Functions
Modern product processes are cross-functionally collaborative. Our team includes product managers, designers, and engineers. Although separate disciplines, we want to be cross-functional because it aligns everyone on goals, reduces meetings, and helps us perform better. For example, we have to marry the user experience with potential capabilities. And some of the best ideas come from engineers – they’re building the product, so they know what’s feasible.
Empower Your Teams
Once you know which outcome you’re striving for, give people autonomy to execute. That’s the secret to shipping upgrades, features, and products quickly. Let the individuals with those specific skills deliver the outcome in the way they think is best. That also creates ownership and accountability, which leads to better outcomes and business results.
Marketplace Challenges
Building a marketplace product presents some unique challenges. How do you create network effects between supply and demand? Not only do you need to find that supply to reach critical mass, but also ensure it matches the other side’s expectations. And once you bring those early network effects to the table, how do you capitalize on them? Which effects should you monetize?
The other challenge is knowing how much of the customer lifecycle you take on. Marketplaces like Airbnb don’t require much post-transaction maintenance. You book, stay, and leave. That’s mostly it. But mergers and acquisitions (M&A) involve many different stages, from finding the right buyer to closing with escrow to due diligence and asset transfer. We had to account for a ton of legal documents too like NDAs, LOIs, and APAs. Acquire.com began as a marketplace where buyers and sellers meet. Today, the whole acquisition process (except escrow) is transacted on-platform.
How far into the process do you want to go? You generate the most value in network-effect land, but you might also want to solve the whole problem. That’s been our approach to acquisitions, identifying the biggest pain points so we can maximize a founder’s exit or help a buyer acquire their dream startup. The stakes are often huge – in the millions of dollars – and generally, when the stakes are higher, people expect more from your product.
The problems of product management have existed for centuries. Sell something and people will always have something to say about it. Your job as product manager is to act on that feedback. Research the problem, acknowledge your capabilities, understand your goals, and collaborate on the best solution. Only then should you push forward to development.
Today, many colleges teach product management. That’s how important software has become in our lives. And if you, as product manager, can discover and deliver a useful, usable, and feasible product, you’ll create a valuable and desirable experience customers will pay to use.
The content on this site is not intended to provide legal, financial or M&A advice. It is for information purposes only, and any links provided are for your convenience. Please seek the services of an M&A professional before entering into any M&A transaction. It is not Acquire’s intention to solicit or interfere with any established relationship you may have with any M&A professional.
