Fireside Chat with Chris Saad, former head of product at Uber

This is a write-up of the fireside chat that Chris Saad gave with the first Sydney Microsoft React cohort. I wrote it up very hastily as he was talking, and in a few places I've regrouped paragraphs and done editing to make it comprehensible to somebody reading it who wasn't in the room; hopefully I haven't put words in Chris' mouth.

Uber was the first company that wasn't something that Chris built. He only took it on the condition that it could be treated as a startup. Still there was a lot of consensus building, and politics to deal with.

Advice for Australian Startups

Chris said that he has heard many Australian startups being started up "to not have a boss"; this isn't what high-growth Silicon Valley startups are like: you don't end up not having a boss... instead your investors are your boss, your customers are your boss.

His number 1 tip for Australian companies: go faster and think bigger. Australian startups often get distracted in their pace, and are often very conservative. The idea is worthless, it's the execution that matters, and you need to execute big.

Focus on building and shipping a product, but have a big vision of where that product will go.

Launcher strategy

If you are very region-specific and entering another market is hard. Then think in terms of franchising: have a city manager. (This is the kind of thing that Uber did well. They also had a data scientist in every team.)

Advisors

There are all sorts of charlatans – particularly in Australia – who will say that they can get funding really easily. There are a lot of professional strategic advisors who don't have any actual experience and are really out of touch. Chris has been doing this for 20 years and only now does he think he can provide useful advice.

Different markets

The Asian market is very different from the USA and Australia. China loves mobile apps that can do 100 different things. The USA is all about one app that does one thing really well.
There are huge differences in scale: Australia is tiny, and the USA is much bigger. You can understand China intellectually, but even having worked in the USA, it's a shock to the system how much bigger and faster Chinese companies are scaling.

Designing a product for scale

Build a repeatable scalable product. If you are spending too much time doing bespoke work for sales teams, or writing things that are one-off for large enterprise customers, you are doing something a bit wrong, or a bit suboptimal.

Scale is about focus, and repeatability. It's about selling what you have built. It's definitely not about building what you can sell. You need to figure out the kernel of the workflow that is repeatable to get more customers more quickly. That's it.
Scaling is not easy. As you get bigger, refactoring becomes harder. It's not just refactoring the code, it's about refactoring the organisation.

To get scale, it's about delegating to the edges. It's about establishing cross-functional teams that can take responsibility for parts of the product. That's how you scale and get paralellisation of the engineering team. Otherwise you end up with bottlenecks.

Roadmaps

Making roadmaps

When you are small, it's easy to set up a roadmap and know what features customers want, because you might only have 5 customers. But when you get 20-100 customers, the dataset changes. Product management decisions need to be data driven. But this is not just analytics – even though these are great sources of information. The number of data sources starts to grow as you get more customers. So eventually, you need to listen to all the data and then have a very strong opinion about what you are trying to build and why.

That roadmap vision has to be clear enough to give you the power to say "no". It should animate the team and empower them to self-direct without constant supervision.

How far ahead to share roadmaps

Question from the audience: our larger clients want to see a roadmap – how far out should you plan?
Answer...

Be very cautious about customers that want to see your roadmap. They think they are so important to your future. That is an unhealthy and unbalanced relationship.
Salesforce gives a rough set of themes of the next quarter. That's about it.

You should have one internally, and you should feel good about it. 3 months for high confidence; 6 months for low confidence should be more than enough.

The goal is to help you say no to things. It helps engineers be a little bit future-proof. It helps run the process (knowing what the pipeline is for ideation and research).

Don't give away your detailed roadmap. It implies that you are something more like an agency for them. That's not what you are doing, you are creating something scalable for millions of customers

Your might abandon your first customers

Your first few customers may be the wrong customers. Just because they paid you, doesn't mean that's who you want to target long term.
That might be sufficient for a lifestyle business, but that's not enough for a startup.

• Are there enough of these customers?
• Do they have deep enough pockets?
• Is the problem acute enough?
• Is the buy cycle fast enough?

Be unafraid to do a hard pivot and lose a bunch of customers.
Choose a market as intentionally as you choose the next feature. Just being born in Australia is not a good enough reason for targeting Australia.
Your existing customers might be holding you back. You are not in the business to satisfy those legacy customers unless they will come along with you in whereever you are going.
Chris says that he often didn't make the hard decisions soon enough. Make the decision and then make really hard cuts to legacy code, legacy processes, legacy contracts.

Selling to enterprises

In order to lock down clients, they will often tell you the things they want you to do. They will muse all day about all the things that they wish you could solve. "Gee whiz, I would buy you if you did these five other things." There's a difference between what customers will tell you what they want and what they will live with.

Come up with a modern way of selling: sell directly to the individual.

If you only have an enterprise sales team, you are probably under-optimising. You also want a self-service funnel so that users don't have to go through IT. You want teams to be able to pick up a credit card and pay for themselves. Infiltrate the company so that IT is forced to adopt the enterprise account in order to control costs.

Small teams will often do an end-run around IT and buy things that are contrary to their corporate IT strategy. Aiming for this is really the only option when you are getting started, because you don't have the features to offer a wide product. As a young company, you can't compete on breadth, integrations and features.

Product Managers

Is there an average time and headcount to bring in a dedicated product manager?

As a startup you are doing three things

• running the business: funding the corp, salesdev, bizdev, etc.
• engineering & writing code
• building a product

You need all three in your company. You are a tech company; you need a cofounder who is an engineer; the other cofounder needs to be able to sell. You also need a product.

It's hard to get people in Australian with product experience. Bring it on-board straight away if you are lacking this area. It's the most underrated. Everyone knows that they need engineering, fundraising and sales, but not everyone knows that they need product.

A product manager is like the director for a movie. It's corralling everyone to put something coherent together on film.

• If the sales person does product management, then everything needs to be done now, now, now to win the next client.
• If the engineer does it, they'll do it the easiest way, and this-will-do attitude will rule.

There's a big difference between product and engineering. There is a tension there between sales, product and engineering. That's how it should be.

Usually the founders take on product – that's how it happens for a long time – and then at some point you get someone dedicated.

When to bring on-board a product manager

Here's the signs that you need a product manager:

• you have a vision in your head, and you tell your engineers, and it comes back broken.
• Or you are spinning your wheels going from account to account and things are evaporating.
• You have five different priorities and you don't know which one to do.

Money isn't that important. Nobody cares how expensive something is, the question is what's the value to it? The goal is to raise the money and spend it efficiently. You should raise funding to last 18 months. Don't hoard it. Bring people on board who can reduce the time to market.

Product Manager Traits

In an ideal world, poach a product manager from somewhere else. Poach from Google, Atlassian, Canva, or wherever; go overseas if you have to. Go get people who have done this before.

Failing that, umm, actually, don't fail at that. There really isn't an alternative in Australia.

Having someone with an engineering background is good, but it needs to be someone who doesn't take it very seriously. A respect for engineering, but a healthy amount of irreverence for it. A respect for design, but a health scepticisim of endless creative design cycles. A respect for data, but having a vision.
Perhaps a prior founder. A lot of founders are going to recycle through in Australia now – a bit like the cycle that happened in Silicon Valley in 2007.

Recognising good and bad product managers

The product managers who are the most frustrating are the ones who act like project managers. They carry information from here to there, and they spend a lot of time doing consensus building, but it's design by committee. They don't have a strong opinion about what the vision should be. These are the most painful. "Oh, you want to do this? Let me work out how to do this."

Product management is not air-traffic control. Not every plane has to land.

How to hire Product Managers

Give product managers homework. At Uber, it will be something like "we have twice as many people taking Ubers to the airport than from the airport". We would say, here are the five questions:

• Why do you think this is happening?
• What would you do to solve? (Write a PRD)
• What would you call it?
• How would you announce it?
• How would you know if you are successful?

It should be that a new-hire product manager jumps instinctively to the things that you've already thought through, and gets you there faster than you got there yourself.

Organisational structure

What's the optimal structure? Initially the product manager should be on the front-line, but as you scale, you need to shield the product manager from direct contact with customers day-in day-out. You need a marketing team who is doing brand and content marketing, gathering customer success stories: they should be creating all sorts of collateral, etc.

Then you want a sales team that are talking to the customer. In a scalable business, sales should be self-service. You want to minimise any kind of bespoke conversation. You need to pair the sales people up with people who deeply understand how the product works in a practical way. You bring them in half-way through the sales process.

Customer success people should own 5-10-20 customers each. Their goal should be to work themselves out of a job. Every sales question, every support question, every implementation question, should be treated as a product fault. They should then work through these with the product team and minimise.

That's how you keep the tight feedback loop with product.

(You also have a developer platform with APIs, there's a whole other thing with developer advocacy.)