08. People

Whether you’re building a product yourself, at your company, or for a non-profit, you need to plan how you’ll get the right people onboard.

Who you'll want and the money you’ll need depends on the problems you’re solving, and how you’re solving them.

The time you’ve taken to understand the problem and your audience now starts to deliver real value.

Costs aren’t kept low by using cut-rate resource, but by only working on what matters.

You should have a great sense of what your users’ more pressing issues are, which gives rise to a natural order of what’s on your roadmap.

Let’s break down how we get from problem to resource to finance.

Who do you need?

If you've followed this guide, you'll already have created a sticky tape prototype to prove you can solve your users' problems.

Our next aim is to create a built prototype, to begin addressing the shortfalls of our initial prototype. If you were hand drawing maps with points of interest (as our example in the earlier chapter), it currently requires your manual effort to solve the problem for each user. Scaleability is the problem in that example, but depending on the problems you're solving, the shortcomings of your sticky-tape solution could be anything. Whatever the shortcomings are, these are your reasons to now test a built prototype.

If you can code, you can create a basic working prototype yourself. It may not look great, or be straightforward to use, but successful prototypes have been built many, many times by a single engineer.

For the non-technical amongst us, this is a skill gap we need to fill extremely carefully.

The shortcomings of your current prototype will also help shape the team we need to create a built prototype.

Let's look at a quick breakdown of some of the people you might be looking for, and what they do:

Product manager
If you've been following the guide thus far, this is you. However you may choose to offload this role to someone else, if for example you're an engineer who wants to focus on engineering. Product managers are the customer when the customer can’t be present, they set a vision and direction for the product, and ultimately decide the problems it solves.

Engineer
Design the architecture, decide what tools to use, as well as the methods and patterns to build, and translate user requirements into code.

Researcher
Conduct deep anthropological, ethnographic and psychological research to understand users, analyse research data, publish conclusions.

Designer
Determine how users interact with the product, design the digital user experience, create media artefacts (e.g. images), oversee usability.

Quality Assurance Engineer (QA)
Design testing procedures (including automation), ensure product meets user requirements, identify bugs before release.

Marketer
Determine marketing strategy, identify opportunities for growth features within product, measure and feedback growth metrics.

Data scientist
Design data model, design data strategies, conduct research, identify insights and lines of enquiry, analyse data, publish conclusions.

Who you'll need to take your prototype to the next stage fundamentally depends on the goals of the next stage.

A built product needs engineering. If the interface is more than a few basic screens, it needs thoughtful design, and so on. As the prototype grows in complexity, the necessity for additional team members grows.

I've seen first-hand the value in having a basic knowledge of how to do someone’s job, before I ask for hundreds to thousands of hours of their time. I’m wasting our collective time without it.

I'm lucky enough to have tried all the disciplines above in a commercial environment, and it's experience that continues to deliver.

If you’re a seasoned product manager working with an existing team, you’ll appreciate the diverse, deep skills required to create something of quality that’s worth paying for. Even so, if you haven’t already tried these roles yourself, I’d strongly encourage you to. Ask your teammates if you can shadow them, and try completing a few basic tasks.

It’s almost a certainty you’ll need engineering to create a product worth paying for, or distributing at scale if growth is your first objective.

So if you’ve proven your solution is what your users need, with a paper prototype or vapourware, taking your product to the next stage by engineering a built prototype is the logical progression.

Are you technical?

I’m not.

Although I’ve learnt to code to a limited level, and I’ve created basic apps in different architectures, I actually consider myself non-technical.

I don’t write code day-to-day. In fact, as of writing this, I haven’t written code for anything in production, for years.

I couldn’t read through code and know how to optimise it. I wouldn’t want to determine what technology is used where.

But I’m technical enough to know what’s important to consider and why, during the lifecycle of a product.

If you are technical, and you’re going to be designing the architecture and writing the code, as you’ll know you’re at a great advantage. We'll cover more than just finding technical expertise in this chapter, so you should value in reading on.

If you’re working within an already established team at your company, you may find it useful to compare my approaches to talent with that of your organisation.

OK, so if you’re non-technical, you don’t yet have a team, and you’re looking to create a software product, where do you start?

Learn to code.

I don’t mean so that you can build your own product, which of course is incredibly helpful, but so that you know what questions to ask down the road. It’ll take a few hours to get a basic understanding of how software is built, lift the veil on some of your uncertainty, and means you should make better decisions.

My level of non-technical, I can just about get away with, but I wouldn’t want to be any less literate.

Understanding how a building gets built is imperative to the architect. Appreciating that materials have tolerances, specific approaches are required to fit non-standard features, that there’s a sequence to the work, are all necessary facets to design in construction. This also follows in product development.

So if you’re planning to build a product, and you’re even less technical than me, I’d strongly suggest getting a hang of the basics, so that you can appreciate the literal foundations required for your design. Some great resources are Code Academy, Tree Treehouse (as you get more advanced).

Get your hands dirty

Are you a researcher? A designer? QA? Marketer? Data Scientist?

I’m not.

Similar to my technical expertise, I have some very basic experience in each, but I am none of these things.

I don’t spend my days performing these roles, and I’m probably not good enough to be great at any of them.

What I can do is understand what these roles need to achieve, in order to make my product approach its potential. As with understanding technology enough to be able to ask the right questions, the same is true of all the product disciplines.

I believe that many of us are capable of undertaking each product role, at a rudimentary level, in order to create an early built prototype, including engineering (if we’re not engineers). However engineering is the common denominator for me, in terms of a role I’ll always delegate.

That’s not because I consider engineering as more important than other roles, but it does often entail a higher barrier to entry (as with data science), before your skills deliver value.

In advance of hiring into my product team, I’ve always tried to fulfil every role, for as long as it made sense to. Typically, and simply, that point is when the upcoming tasks are beyond my skills (so it doesn’t take long before I start hiring…). By kicking off the tasks in each discipline, I gain a great appreciation for what success will look like in each role, because the mix is slightly different with each product you build. It also allows me to orchestrate and interweave tasks quickly and iteratively, at the very start.

So instead of sending you to courses on each of these subjects (as with engineering), I’ve distilled down the basic tasks you can undertake yourself to support your early built prototype (included in the chapter Built Prototypes).

Finding great people

Now we can go in search for someone with the expertise we lack, to help build our product.

Do you need people who will work with you full-time? Part-time? Freelance? Should you employ an agency to build your product for you?

I can give some simple answers here. Ideally you want someone to work with you full-time, and if not, then part-time. Freelancers are great because you can often find strong talent at short notice, but you lose the knowledge they acquire as soon they move to their next project (which they’ll do quickly). Agencies are a great way to spend a lot of money and build the wrong thing.

Building your product will require so many iterations and the accumulation of knowledge amongst your team, it’s simply poor economics to fill long-term positions with people who you know for certain, will not be working on your product in 6 months.

Freelance resource is of great value, but only when you know you’ll require expertise for a defined amount of time, and will not require that role to be filled ongoing.

Going through the process thus far, you’ll have seen how much you’ve learnt from customer interaction. Now imagine you create a product to solve their problem, and they start using it. The feedback you’ll receive should be overwhelming, with ideas, bugs, things that worked, things that didn’t, and you want the most efficient process which can interpret this information and make the necessary changes.

It therefore stands to reason that you want people with the most knowledge, able to react the quickest, with the least supervision required. That leads to the preference as being a full-time teammate, part-time, freelancer, then agency.

It’s very unlikely you’ll build a product, be able to let the team go, and continue selling it successfully years after, by yourself. Your community will demand change, as will competitors and the market as a whole.

We also want the people who’ll share this journey with us to care as much as we do.

We’re looking for three things, in this order:

• Someone you trust.
• Someone you can work with.
• Someone who’s very talented.

When choosing teammates, imagination is probably the only limit to the many aspects of personality and facets to work ethic, which we need to consider. Fundamentally though you want someone who shares your need for objectivity, customer-centricity and ideally shares your motives.

I will always choose someone I can work with productively over pure talent. It’s a non sequitur to have someone you can’t work with, yet is gifted.

Like having a supercar with no steering wheel. You don’t always have to agree, and in fact it’s important to constructively disagree. But you need to be able to get things done.

With that said, how do we find the right people? Once again, I suggest there’s a preferential order.

• People you’ve already worked with
• People you’ve known a long time
• People have been recommended by someone you trust

Don’t worry, there’s a very good chance you don’t know anyone who meets any of these criteria. Here’s a challenge to you though; you should. Useful eh? No, at least not yet. If we have a problem that’s worth solving, that’s worth investing time, energy and money into, it’s worth taking time to find the right people to help us realise it.

Networking

A dreaded term for many, but often a driving force behind great products (and businesses).

Why is networking so effective? It saves you time and is more reliable than its alternatives.

Let’s look at finding tech talent. If you try to find someone by placing a job ad, let’s say on a website dedicated to startup hiring, you’ll likely receive hundreds of applications which you’ll need to wade through. You’ll then shortlist those you want to speak to. Next, you arrange to call or video chat, and then you undertake those conversations. You’ll require at least another round of convos, but probably two, before you feel like making someone an offer, and even then, there’s no guarantee they’ll accept.

It’s time-consuming and you’re hiring based on very little interaction with the person.

Now consider finding some local groups dedicated to startups, hackathons, tech, or new graduates - basically wherever you’d expect to find engineers (you can try online if there are non close-by). Meeting and chatting to people, sharing your ideas, listening to talks by experts. It’s scary at first, but you’ll quickly see the value in it. A couple of hours’ invested in this type of setting now gives you an opportunity to ask for advice, find out if anyone is interested in helping build a product, or knows someone who might be. If you’ve been impressed with an individual, ask their advice, see who they’d hire to work on a product with them.

This route still means you look through their resume, ask for references, interview and so on, but it’s a more reliable and efficient route to finding quality talent. You’re also plugged into a network where you can possibly find more people to join your cause in future, and you can contribute to in time, paying it forward.

Even if you’re hiring into a company you work for, aside from making good hires, going above and beyond to find stellar teammates will make your life much happier and fulfilled. The gargantuan tech companies routinely ask new hires for their trusted network of ex-colleagues, which demonstrates the value of recommendations.

You can share the paper prototypes which you’ve already tested with users, talk about the problems they experience with authority, and inspire people with your passion to find a solution. Conversation should come easy with the research and testing you’ve already done, and from the perspective of engineers you’re trying to attract, finding product people who’ve taken the smart route is a desirable rarity.

That said, if you’ve spoken to some people and haven’t yet clicked, I wouldn’t recommend just pressing ahead anyway. This isn’t the time to take shortcuts. Cast your net wider and keep talking until you find someone you’d love to work with.

Aligning interests

Imagine shopping at a physical store, where you were looking at equipment for a dangerous mountaineering expedition. But these weren’t just any pieces of equipment; they morphed and evolved over time, and might not even be there when you need them. Fast-forward to a thousand feet from the summit, and you’d probably be a little nervous.

You’d spend a lot more time choosing, testing and researching those tools before you made your purchase. But people aren’t tools (obviously) and they’re even more mercurial than my poor analogy eluded to. It’s partly what makes us so successful as a species, but also why people are the hardest part to get right in any organisation. We change constantly.

That’s why establishing aligned interests and common goals before you begin is crucial. I’ve fallen foul of this with an investor, and it cost us the company.

Having foundations which are unshakeable means change can happen, and therefore crucial adaptation, whilst reducing the chances the team becomes dysfunctional and breaks up completely.

If you’ve followed this guide, you’ll already have identified your motivations. You’re deeply routed in the problem you’re solving, and you should care about the people you’re solving it for. It will matter to you, that the team you assemble to help build the solution cares too.

These are a few foundational precepts that I look for in any team members:

• Honest
• Customer-focused
• Value data over opinion
• Ready to give and receive criticism
• Adaptable
• Smart
• Child-like curiosity
• Entrepreneurial

Nothing revolutionary there, but laying out your principles, and aligning their interests (like wanting to solve the problem, or learn a new industry etc), help organise the team without effort.

Fundamentally you’re looking for someone whose technical expertise you trust, and who shares common values and goals.

Salary or equity?

How do you incentivise your team? Depends on the structure around your product.

There are many guides on starting startups far better qualified to explore this topic, but I’ll make a brief reference so that you can do your own research.

If you’re working within an existing company, this section isn’t relevant, so feel free to move on.

If you’re starting out yourself, you believe you’re onto something with your solution, and you’ve found someone to help you build it, now’s the time to formalise things by incorporating a company. Companies are the legal entities that tie together the myriad of legal, financial and practical necessities which you’ll need to take your concept from an idea to something saleable.

Look at the jurisdiction you’re operating within (i.e. the country and industry), and get some legal advice on how and what you need to set up.

Specifically with regards to how you incentivise someone to work with you to deliver the product, you broadly have two means; salary and equity (and a mixture of both).

The likelihood is your teammate will require a salary, and if you’re being smart, you’ll give them equity.

I’ve come to the opinion that the more a company is owned by its employees, the better. I’d encourage you to think about splitting equity equally with your first hires. When people own something, they care more, and when they care more, they try harder. It’s one of the strongest positive signals you can send to your team and people thinking of joining.

I won’t go further here on the subject of startup structures, as I’d encourage you to study this as a subject of its own. I highly recommend Paul Graham's How to Start a Startup essay, and the YouTube lecture series How to Start a Startup with Sam Altman.

Next let's look at building a working prototype.

CHECKLIST

Have you found the right people to work with?

Who do you need?
Your unbuilt prototypes have shown you what you need to test next with a built prototype. Who do you need to help you build it?

Jack of all trades
You've undertaken some basic tasks from different disciplines, so that you understand more about what you're of asking your teammates.

Networking
You've reached out to different communities, through different mediums, so that you can talk to people and get personal recommendations of who to invite to join you.