Andy Pitre spent over 15 years helping transform HubSpot from a 100-person inbound marketing company with $10 million in revenue into a $3 billion multi-product platform serving more than 250,000 customers. His journey mirrors that growth. Andy joined as an onboarding specialist, complained about the product enough that the team made him a product manager to “shut him up,” in his words. Then led the small team that built HubSpot Customer Relationship Management (CRM) from scratch. That bet transformed HubSpot from a single-product company into a software juggernaut spanning marketing, sales, service and content management.

By the time Andy stepped down as head of product and user experience last summer, he had developed a deceptively simple philosophy: Obsess over customers, move fast and iterate, and assume you’re wrong on most of your decisions. That last principle proves hardest for founders to internalize. The instinct is to wait and build more, one more feature or a better release before shipping. Andy argues the opposite: Being wrong is inevitable, so the goal is to learn where you’re wrong as quickly as possible, and you can only do that by getting real working software in the hands of customers. He shared those insights, along with choosing quality over scope, and how maintenance costs more than building.

Misjudging impact nearly guarantees wasted effort

Andy’s prioritization framework starts with a two-by-two matrix: One axis measures how easy or difficult something is to build. The other axis measures customer impact: High or low. The ideal quadrant combines easy builds with huge customer impact, and early-stage products offer the most opportunities to find these wins. The problem is that most product people, including Andy, consistently misjudge which quadrant they’re operating in.

“I’ve never had an idea where I’ve said, ‘Ah, this is probably low impact,’ and then it turns out to be hugely impactful. That almost never happens,” Andy said. “I’ve had a lot of ideas where I’ve said, ‘This is going to be incredible, this is going to be the best thing that we’ve ever built,’ and it’s fallen flat on its face.”

The same directional bias applies to difficulty. “I’ve also almost never been wrong in the better direction about how hard something is going to be to build. I’ve never said, ‘Oh man, this thing is going to be really hard,’ and then it turned out it was really easy,” Andy said. “Usually I say, ‘Ah, this thing’s going to be really easy. It’s only going to take us a week to build,’ and then 2 months later, we still haven’t shipped it.”

These twin biases create a predictable migration. “You’re going to think that you’re in the good quadrant of high-impact, low-effort features. And over time, you’re going to start shifting more and more into that bad quadrant where you don’t want to be,” Andy said. Teams that don’t recognize this pattern end up building expensive features that deliver minimal value.

The solution requires breaking high-effort work into smaller pieces that can be validated quickly. High-effort projects make sense for mature products with provable returns on investment, like re-architecting a database to reduce costs. For new feature development, the stakes change. “Try to break things down into smaller chunks, get them in front of customers and validate before you put more and more resources into it,” Andy said.

Sacrifice scope to preserve quality

The pushback Andy consistently hears to his “move fast and iterate” philosophy centers on quality. Isn’t he just advocating for shipping half-baked products to customers? While that concern is valid, Andy thinks about trade-offs through a triangle framework.

“On one side, you’ve got time. On the other side, you’ve got quality. And on the other side, you’ve got scope,” Andy said. “And you have to sacrifice. You assume that you can’t sacrifice time. You have to move fast. That’s a non-negotiable.”

That leaves quality and scope. The instinct is to sacrifice quality to preserve scope, shipping everything you planned but at a lower standard. “The thing that you want to do is instead of sacrificing quality, you want to sacrifice scope,” Andy said. “You need fewer requirements than you think. You need fewer requirements, you need fewer features, you need less than you think,” Andy said. “You should always be pushing yourself to scope things down.”

When HubSpot built its CRM, Andy wanted resizable table columns (among many, many other things). He believed it would significantly improve usability. But including that feature would have delayed getting working software in the hands of customers, so the team shipped with static columns instead. Unsurprisingly, customers requested the ability to resize columns, and that feedback went into the backlog. 

More importantly, customers provided feedback on problems Andy never anticipated. Those insights only emerged because working software reached users before every conceivable feature was built. Customers will always request missing features after launch. That doesn’t represent failure. Those requests become your roadmap for the next iteration, informed by real usage rather than speculation. It turns out, compared to the other customer feedback, resizing columns turned out to be a relatively low priority feature. 

Product managers should accelerate teams, not slow them down

One of the first lessons Andy learned when transitioning from customer success to product management came from his new team. “You work for the team, not the other way around,” he said.

That inverted hierarchy shapes how Andy thinks about the product manager’s role. Most companies start with engineers who build and make their own product decisions. Product managers enter the picture when engineers realize they need help. “I need to spend my time actually building this thing, and we need to hire some ‘idiot’ like Andy, who we don’t have to pay as much as an engineer to go and talk to a bunch of customers and figure out where we want to build next,” Andy said.

The ideal scenario has product managers thinking ahead of the current sprint. “Ideally, as a product manager, you want to be thinking about the next thing or thinking about two or three things ahead, figuring out what the direction is going to be for the team,” Andy said. “And in that world, you’re not going to be interfering with the team. They’re going to feel like, I know what I’m doing, I’m moving forward, and you’re out figuring out what’s on the horizon.”

Another critical skill is recognizing when you’re adding friction instead of value. “Sometimes PMs come in and they’re like, ‘I want to add value to the team and I want to help us do sprints and I want to help us do tracking,’” Andy said. “A lot of the time, you end up creating more work for the team than you need, especially in early-stage companies. Know when to get out of the way and let the team cook.”

Teams often slow down because of indecision. “You reach a point where you’re like, ‘Oh, we could do this, we could do this, we could do this,’ and you end up spending a week debating what you’re going to build next instead of actually having hands on keyboards building,” Andy said.

That’s where product managers need to force decisions. When Andy ran product at HubSpot, David Cancel reinforced a principle that became central to Andy’s approach: Any decision is better than no decision. 

“Don’t be afraid of making the decision, and don’t be afraid of being wrong,” Andy said. “If you’re trying to force yourself to move fast, iterate, think small, iterate small, then the risk of any one particular decision shouldn’t be that large.”

Product-market fit determines when bugs become priorities

As HubSpot matured, the company developed a framework called “Mainsail” to create a hierarchy of priorities for product teams. “At the bottom level, you had security. And then one level above that, you had infrastructure and reliability and performance. And then one level above that, you had bugs. And then one level above that, you had features,” Andy said. 

That framework took a decade to implement. For early-stage products, the calculus changes entirely. “If you’re pre-product-market fit, like you haven’t truly gotten usage of your product, then don’t worry about the bugs,” Andy said. “You’ve got bigger problems. You’ve got a product that hasn’t created value for your customers yet.”

The tension becomes acute when a small number of customers rely on your product while you’re trying to scale. One founder asked Andy how to balance fixing bugs for two existing customers versus building features to acquire 100 more. Andy said the answer depends on your business model and goals.

“Once you have one customer who says, ‘I love this thing, and you can rip it from my cold, dead hands,’ it’s pretty easy to get to 10, because there’s going to be 10 other customers that are like that one customer,” Andy said. “Once you have 10 customers who say that, it’s easier to get to 100, it’s easier to get to 1,000.”

The strategic question isn’t about the bugs themselves. It’s about whether your business model requires 100 deeply satisfied customers or 10,000 casual users. If those two customers represent your entire addressable market and pay significant annual contracts, bugs matter immediately. If you need volume to survive, the math changes.

“Once you have a product that is creating value for your customers and your customers rely on, you need to shift your mentality and you need to say, ‘Yeah, we’re going to fix the bugs. We’re going to get the reliability up,'” Andy said. “This is a mission-critical piece of software for our customers, and we owe it to them to make sure that this thing is rock solid.”

Maintenance costs always exceed building costs

HubSpot developed what Andy calls a “builder mentality” over its years of growth. When the team identified a need for internal tooling or systems, the immediate instinct was to build rather than buy. 

“You think about tooling that you need to build, and you say, ‘We could build that really quickly. We could build that system. We could build that thing. We could build that internally,’” Andy said. “We could customize it and make it work perfectly for our team, rather than having to buy something and then adapt it to customize it for our team.”

The upfront math often favors building. Custom solutions can be developed quickly and tailored to internal workflows without the friction of adopting external software. That’s not where the story ends, however.

“Just because you can build something really quickly rather than buying an off-the-shelf solution, the upfront cost might be really low in building that thing, but then what’s the cost of maintaining it and making it better and making it work and adapting it over time?” Andy said.

Internal tools compete for engineering resources with customer-facing features, and that means they rarely receive the sustained investment needed to keep pace with evolving needs.

“I’ve learned the hard way over the years that oftentimes it’s better to buy something rather than to try to build it yourself,” Andy said. “Because you start to incur the debt of maintaining those systems, and it ends up eating up a bunch of your resources that could otherwise go toward building stuff for customers.”

Sleep soundly when customers use your product

When Andy talks to startups or reviews products at HubSpot, his first question cuts straight to validation: Is anyone using this? “The thing that makes me most nervous is when they don’t have a working product in the hands of customers and they’re not getting that customer feedback,” Andy said. “The same thing was true at HubSpot when we were building new products and new features.”

The psychological difference between building with and without customer feedback is dramatic. “When I’m working on something, or when I hear about somebody working on something, and I don’t have it in the hands of customers, I’m nervous,” Andy said. “I’m losing sleep. I’m worried.”

Customer feedback reverses that anxiety, even when the feedback is brutal. “When I have a product in the hands of customers, I’m sleeping like a baby,” Andy said. “Even if you get it in front of customers and the feedback is, ‘This thing sucks, and it’s terrible, and I hate it,’ and it’s totally wrong, I feel a sense of calm, because I’m like, good. I didn’t want to have to wait 6 months to get the answer to that question.”

In the end, Andy’s philosophy for success is simple. “You just have to pick, assume that you’re probably going to be some degree of wrong, and continue: Ship it, get in front of customers, learn, see what’s learned from technology improvements, you get customer feedback, you iterate, and you continue to get closer and closer to the right thing,” Andy said.