Skip to main content
Collapse Menu
Dave Weiss, Co-founder, President and CTO of Hatch
Dave Weiss, Co-founder, President and CTO of Hatch

Building great product teams

Dave Weiss is the President and CTO of Hatch, a company he co-founded with his wife, and CEO, Ann Crady Weiss that designs and builds smart sleep monitoring devices. Dave is also part of the Lazaridis Expert Network and is a perennial favourite with Lazaridis ScaleUp companies for his enlightening and entertaining Product Program Weekend sessions.

How do you define the “product team”?
Loosely put, the product team is the people responsible for building and deploying new stuff. For technology startups or scale-ups, whether it’s software or connected hardware, the product team typically consists of a product manager, designers, engineers, and QA.

How do you hire a great product team?
Before hiring anyone, it’s important to define your company values. Company values are not generic statements that apply to any company. They are the things that make you, you. You want to hire people who are highly aligned with these values.

For example, one of our values at Hatch is that our product team is built with very senior people who aren’t afraid to get their hands dirty. Everyone is willing to pick up a shovel. I’m the founder, and if somebody’s computer needs IT help, I’m happy to fix it. No one is too good for anything.

There are tons of senior people out there who manage groups of 30 or 50 people and spend their days in meetings. They only wish they could get back to building things. In their hearts, they are builders. This is the type of person we want to hire.

How do you screen for this mindset?
I often ask candidates how they approach doing something they have never done before. Just because you are an expert in one area doesn’t mean you are comfortable taking on new things. As a start-up, you don’t have the resources to fill every role with an expert.

For example, our designer had no previous experience with product packaging. Instead of avoiding it or wanting to hire a bunch of people, they were excited to have the opportunity to do this cool, new thing. Not everyone has that emotional reaction.

During the interview process, I try to gauge this, especially if the candidate is coming from a larger company. People try to hide behind their expertise. They have their hammer. They like their hammer. Our response to that is they should work somewhere else.

Product manager vs. project manager


When recruiting for a product team, you will need to choose between different types of “product managers.”

“There’s a spectrum. On one end, you have a true product manager. This is someone who is great at envisioning products customers will love. On the other end of the spectrum, you have what I deem as more of a project manager type; someone who can run an efficient project process, has a bunch of checklists, and is extremely organized.”

For Dave, the choice is clear.

“I really lean towards hiring true product managers. I test for a high level of creativity during the recruiting process because having a team that’s well-run but is missing that creative spark or customer understanding doesn’t produce good output.”

How does hiring senior people give you an advantage?
Smaller product teams deliver better work than larger product teams. Communication is easier, and small team can work faster and more efficiently. One of the ways to keep teams small is to make sure you have the most senior people possible. Senior people like working with other senior people who are experts at their craft. If you’re a start-up, there is no place for junior people. Try to keep your teams as small as possible with the most senior resources you can afford.

That said, with certain senior people, there is the risk of encountering ego or communication issues. None of that works at our company, and we pass on very senior people who aren’t a good fit from a cultural perspective.

 

How involved are you in the day-to-day management of your product teams?
Product teams should be autonomous. I provide a general framework. The team figures out the process. If I provide the right level of clarity around objectives, and the team has a bunch of smart people that understand what we’re trying to do, it can be responsible for itself.

That being said, in several cases, I am a card-carrying member of one of those teams. My level of involvement is often as a product person or technologist. I didn’t start this company to run a bunch of teams. I started it because I like to build. I want to be close to metal.

The reality is, even when I am involved, the team is ultimately responsible. While I provide some loose boundaries, our process is a living, breathing thing. It really depends on the stage of the company, product, and other stuff going on. The problem with most tools and processes is that you’re taking, what should be, a self-determining organism and saying, you must do this.

One person every team needs


Every team should have at least one mathlete to deal with incomplete data. During the product-building phase, you’ll often get survey results, feedback, or other types of data that can help guide decisions. You need to be able to synthesize and understand it. The thing is, you never have perfect and complete data. You have to fill in the gaps. Data can say anything you want it to say, so you need someone who is “mathletic” enough to fill the gaps and ensure you’re making the right, data-driven decisions.

How do you maintain alignment across teams?
We do what I call a scrum of scrums. The product team has a scrum. Marketing has their own scrum. Finance and operations has their scrum. We all come together once a week to share the most important stuff the other teams need to know. That’s how we keep alignment, dependencies, and transparency across teams.

How do you measure product team success?
I consider success to be a mix of things. How did we do operationally to get the product out the door? Does it work and is it stable? Does it meet our business objectives? Do people like it?

It’s hard for me to divorce the results from the process. We can have a sprint team that works extremely well and meets all of their deadlines, and despite that, we put together a product that our customers just don’t like. They don’t use it. They don’t buy it. They aren’t engaged. It’s hard to call that a success. Nobody wants a participation trophy.

Ultimately, the product’s success influences the company’s bottom line. For a start-up, you have one or two product developments that can make or break a company. Our employees took this job because they want to be in the line of fire. If they win, then the company wins and their shares are worth something. You want people to love what they do, love their job, love their company, to be motivated for the long-term. If they don’t, then go do something else.

 

Learn more about the Lazaridis Expert Network.

Like this post? Sign up for our newsletter for more great content. 

Unknown Spif - $key