Building Software in a Team of Eight

Putting a product out in the world is really difficult.

It starts easy enough, especially when you're a one person show.

When you start out you can be opinionated. You can make bets. You can just get stuff done.

The more people you throw in the mix, the easier some things get. But some things get harder. Product management is one of those things.

As you grow, even to a team of just eight people (small when compared to most funded tech companies) you have eight voices and opinions on where the future of the company should go.

Here's a few thoughts on how to bring eight people together to build a great product, and ultimately a great company.

Democracy vs dictatorship

A lot of companies present themselves to the world as being a utopia for developers, designers and product people. They pitch their workplace as an environment where you can develop anything, push it live to customers, and watch as the money keeps rolling in.

Product experimentation, trial and error, and getting things in front of customers ASAP is essential. But things turn to chaos extremely quickly if you don't have a higher level vision, and an overall framework of priorities as a company.

What matters is giving everyone a voice, ensuring it's heard, and then making a decision for the whole company that gets everyone working together in the same direction. Aligning everyone is key.

Sometimes the decisions may be right, often they'll be wrong. But the worst situation is to spend weeks or months debating, and not deciding where to go next.

Sometimes you just need to make a call and move forward.

Lead, follow, or get the hell out of the way.

The loudest voice

In team discussions, there's often someone who can speak louder than everyone else – someone who is more aggressive at getting their opinions heard. Good teams building good products ensure everyone's voice is heard. Good teams ensure once everyone has been heard, that the best ideas win, not the loudest.

The most cynical voice

In an earlier post, I wrote about how fragile ideas can be. Some of the best products and features can start as barely formed thoughts that are very easy to squash with a small comment thrown in a team discussion.

You have to work extremely hard – you have to obsess over this – to avoid ideas being shot down too soon. People often err on the side of caution, and great things can often start as ridiculous sounding ideas. There are many things to laugh at in this world, but the product ideas of your team are not a laughing matter. No matter how ludicrous they seem, early stage ideas need to be listened to and given time to fully form or fizzle out on their own merit.

Don't let the most cynical voices of your team drown out the potential of your most crazy ridiculous ideas. There is a time to focus and say no to things, and that's later in the process.

Focus vs experimentation

Everyone knows the best startups succeed because they're extremely focused on a small number of things that they obsess over. Almost every piece of product management advice includes some mention of how important it is to focus and not do too much with too little.

But focus is hard. Focus means saying no to lots of things. Saying no to lots of very good things.

Also seemingly in contradiction to the advice of increasing your focus, there's a lot of advice to always be experimenting, to be iterating and trying new things out. To get more ideas in front of your customers and to see what they like and what they don't like.

My take on this is that focus does not necessarily mean "build one feature and don't build anything more." To me, having focus as a company is about having focus around a set of problems, and a set of (potential) customers. It's about focusing on what you're solving, less what you're building.

It's OK to build 10 new experimental features between now and Christmas that all aim to solve one specific problem for your customers. It's less OK to build 10 features in random disparate areas of your product without a clear reason other than "we wanted to do that for ages."

It's very easy to ship new code, and for that to feel like progress. But what I fear is getting 3 months down the road having spent the collective work of eight people to have minimal change to any meaningful business metrics. If you can get the team paddling in the same direction and obsessing over solving the same problems then you're likely to make some real progress as a business.

Subscribe for Updates

Powered by GoSquared