The Zen of Building a Product Team

How to manage people and priorities for a growing team without being anyone’s boss.

One of the things I like most about working at Eyeo is the flat hierarchy. Everyone reports to a few senior managers, but otherwise people manage themselves. As a company, we define clear goals, and then allow everyone to apply their expertise however best supports those goals. And even though we’re over 60 people strong – half of which operate remotely all over the world – somehow it all works.

More recently, we hired a Product Designer and another Product Manager to fill out the team. Now what? How do we scale our capacity, while maintaining a “flat” organization? It definitely sounds like marketing spin, if not complete fantasy. But so far I’ve seen it work in practice, and on a daily basis. Someway, we find a way… usually without getting in each others way.

After giving this considerable thought, and reflection on my own experiences, below is my current approach to building a killer product team, but with a healthy does of skepticism. To paraphrase a popular adage, no plan survives first contact with reality.

But you have to start somewhere, right?


Get new hires started quickly, and support them completely.

If you hire self-directed people capable of delivering superior work, then they likely crave input and context even before starting. So, provide them with the resources they need to better understand your products a week or two before. Let them self-service their curiosity, and then ask specific questions later. When they do start – officially – you can give them problems to solve their very first week. Meanwhile, be available to answer questions, talk through ideas, provide file assets, or do whatever else is needed to help them succeed. No request is too big or too small.

Prove your commitment to the success of others from the very beginning, and they will be more likely to genuinely support your decisions later on.

Delegate ownership, not projects.

If everyone on the team has comparable skills, then they should be permitted and encouraged to work on a variety of projects. But in the end, each product does need a final decision maker. Therefore, give those with similar roles authority over a specific product or problem. For example, one person might own the mobile version of a product, while the other owns the desktop version. However, they should always be willing and able to help each other as needed (or desired), on any project.

This way there is accountability, but nobody gets bored or feels trapped thinking about the same problems over and over again.

Connect people working on similar problems.

When giving someone the authority to solve particular problems, also make certain that they work together with at least one other teammate to support the larger goal(s). This approach offers checks and balances, since they will naturally challenge one another in search of deeper understanding and broader insight. “Management” may be necessary to ensure that communication and delivery happen smoothly, efficiently, and productively. But once a person is connected to the right teammates, get out their way.

If the team member understands the problem and requirements fully, you won’t have to micromanage their individual contributions.

Maximize transparency. Minimize process.

The Open Source community is clearly capable to working collaborative, globally, on common projects, and with clear goals / deliverables. So why not make this the standard approach for internal product teams as well?

By simply documenting all the problems, goals, priorities, research activities, etcetera, anyone can find answers to their questions more easily, and they will understand the “why” much more easily. Inviting everyone to participate in a minimal process, and then allowing them to ask questions organically, also helps people in different time zones, or with different expertise, to find the information they need to do their job more effectively.

The context and completeness of information is everything. This is the key to unlocking great potential, because once smart people start working together on a common problem, they will quickly arrive at better decisions than you ever could on your own.

Never ask a software engineer how long it will take to build something.

Software development is not a linear process with defined tasks and timeliness. It’s jungle warfare, and everyone’s always hacking something. Engineers have to figure out exceedingly complex problems all the time, and often without knowing what challenges they’ll run into next. Therefore, you’re never helping by asking them “when can you get that done?” because they honestly can’t tell you.

Instead, ask them what’s blocking their progress. Work together to solve problems they can’t by themselves. The faster you can connect the dots, and get then get the right people talking to each other, the faster a developer can solve the enormous list of problems you gave them to solve.

Remember, your engineers want to ship amazing products – preferably ones that operate as intended, and without flaws or inconsistencies. Let them take as much damn time as they need to figure it out, and fully support them along the way. In the end, users will thank you for it.

Leave no one behind. Ever.

If somebody needs help, spend time learning about their problems before offering solutions. Then actively help them help themselves.

If somebody says something upsetting, confront it directly, and in the moment (whenever possible). Then seek new solutions instead of further blame.

If somebody feels lost or unheard, help them find their way or their voice. Ask them how you can help, and then follow through. A motivated, empowered individual will likely find another way to reengage with the overall team.

These, and other individual circumstances, will arise no matter the company culture or existing processes in place. It’s okay and totally normal, but it’s still your responsibility to respond with empathy and action.

Everyone matters. Encourage respect and cooperation, but never tolerate blame or inaction.

Own your mistakes and failures.

Even the best, most well intentioned plans go terribly wrong. Longterm success is a collective effort, over time, through trial and error. A growing team will present all sorts of problems or challenges you cannot possibly anticipate. So learn what exactly went wrong, and why. Then fix it or try something else, and move on.

Indeed, you’ll fuck up plenty of times – especially the harder you try. But embracing failure is the first step to finding a credible solution that will produce better results, for everyone.

Just don’t ever fail the same way twice.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s