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.)

Using AI for compliance

https://itbrief.com.au/story/why-ai-will-play-crucial-role-climate-compliance/

My contribution to the Piano Guys' success

Don't listen too closely -- I haven't done any jazz improvisation in nearly 20 years. It kinda shows.

Cryptocurrencies and the Australian Tax Office's asset tracking rules

While I'm on a roll getting quoted on the taxation and technology, the ATO has issued some guidelines around record keeping for cryptocurrencies which are onerous and unnecessary (and thus failing to comply with the taxpayers' charter).

Essentially, the tax office is asking taxpayers to record the Australian dollar value of any cryptocurrency transactions at the time that they occurred. This seems harmless enough because it is consistent with any other taxable asset.

But it is asking taxpayers to keep records that the tax office already has.

The tax office (perhaps in conjunction with Austrac) will of necessity be keeping copies of all the ledgers or all the major cryptocurrencies. This is not a particularly large dataset -- HPE or Dell could easily sell a single system capable of holding all this data and perform sophisticated analysis over it. If the tax office and/or Austrac weren't at least attempting to keep somewhat on top of the cryptocurrency transactions of criminal elements, then that's a major problem!

So, given that the tax office already has information about every transaction anyway (including when it happened, and the public wallet addresses involved in the transaction), why is it necessary for tax payers to do so as well?

Indeed, the missing piece of information that the tax office would really like is the association between TFNs (or SMSF ids) and public wallet addresses. So why not simply ask for this information? This would help the tax office in its investigations immensely, and creates a ready-made CGT record-keeping system for the taxpayer.

The simple way would be for the ATO to provide a web interface where tax payers could enter their public wallet addresses for each currency that they own together with the relevant TFN. A more sophisticated approach could be done by having the taxpayer complete a transaction on the blockchain to prove the association.

Having obtained this TFN-to-wallet address mapping, the tax office can automatically calculate the CGT applicable for the tax payer. In the same way that taxpayers can take advantage of a pre-filled tax declaration for the PAYG information provided by their employers, so too could all cryptocurrency transactions be handled the same way.

Note that this does not apply very well for Monero, but would be fine for Bitcoin in all its variants, ethereum, litecoin and all the other major currencies.

The advice the tax office is giving is simply archaic and utterly misses the opportunities of taxation paperwork simplification inherent in having a public blockchain.

Currency-to-currency transactions are even more problematic; the tax office can issue guidance here that would be quite straightforward and automatic, but instead relies on taxpayer estimation over matters which are ambiguous without guidance.

For example, how to handle a cryptocurrency fork? Consider the fork that created Bitcoin Cash. On August 1st 2017, suddenly every tax payer who previously had Bitcoin now also had bitcoin cash, and that bitcoin cash had a non-zero value. What cost base should be used for that? $0 because on September 30th Bitcoin Cash was just a concept, and worthless? Or should it be the value of bitcoin cash on its first transaction? Or should it be the value of bitcoin on the last common block? Or the cost base of the bitcoin when it was purchased?

All of these answers have serious accounting challenges, because in some sense they necessarily involve double dipping.

Associated with this is that there are low-profile forks that a taxpayer might only find out about much later: bitcoin gold for example. It's entirely possible that a cryptocurrency owner may discover that years after they have emptied a wallet -- and perhaps even trashed the original paperwork that they used -- that they may have significant quantities of wealth in a previously unknown fork of a wallet. The ethereum fork is almost old enough that this could be relevant soon.

Finally, since there is a real-time bidding system on many exchanges (e.g. bitcoin to ethereum was traditionally done this way) the actual price achieved or paid might be dramatically different to the published prices of that day. A taxpayer might have added a zero to an offer (and still had it accepted), or left one off (and sold very cheaply). This would not be reflected in any official price; but this is the kind of thing that the tax office could infer automatically from a system if TFNs were associated with wallet addresses.

So why isn't the tax office simply asking tax payers to match their wallet addresses with their TFNs and then telling the taxpayers how much to include on their tax returns? It is logically equivalent to having TFN matching with bank accounts and superannuation accounts (all of which already happens). This would be a much simpler system for both the ATO and tax payers.

Software treated strangely by tax laws, part 1 ...

It's tax time, and small-medium enterprises are frantically evaluating what assets they can write off. Eligible assets include things like cars, vans, kitchens, machinery provided they cost less than $20,000. However, the exclusion of one particular asset from the instant deduction scheme is adding to the tax time blues. In-house software.

As it stands, in-house software is only deductible under the uniform capital allowances (UCA) rules or the simplified depreciation rules for small business entities. This lack of a tax break for SMEs means there is less of an incentive to invest in software and therefore innovate. By deliberately penalising low-tech companies, it is preventing them from delving into high-tech such as artificial intelligence which is set to have a hugely transformative effect on Australia’s economy. If we’re to establish ourselves as world-beaters in innovation then tax reforms are in order.

-- quoting myself as I was quoted in https://www.dynamicbusiness.com.au/featured/lets-talk-eofy.html 

Another blog quoting me about using chatbots for customer service

https://www.telcosolutions.net/blog/blog/omnichannel-customer-services-customer-contact-strategy/

Getting your fair share of AWS EC2, VMware, Hyper-V, etc.

One of the problems with virtualised infrastructure -- especially cloud servers -- is that your programs don't always get the CPU time that they need. The CPU time for your application is shared between CPU time given to other virtual machines on the same hardware. This is good for cost savings, but it would be nice to know how badly you are being affected by this.

I had a customer who had some really interesting VMware scheduling problems. They had a large number of multi-cpu virtual machines. VMware can't schedule a 4-cpu virtual machine unless there are 4 physical CPUs free. So even if you only have one tiny job to run on one CPU, VMware can't just schedule that one CPU -- it has to wait until at least 4 are available. (Incidentally, those other 3 CPUs that are scheduled but do nothing count towards co-stop% which is another interesting performance-and-tuning metric.)

As it turns out, almost all their virtual machines had some small tasks going on in the background (e.g. cluster heartbeats), so VMware tried very hard to schedule them all as best as it could, but the result wasn't pretty. How bad was it?

I wrote a little program that slept for a second, woke up, recorded the time, and then went back to sleep again. It kept statistics about how delayed it was. There were some horror stories --  there were virtual machines that received no CPU time for more than 90 seconds on occasions! No wonder their clusters kept crashing -- the cluster heartbeat time was only 30 seconds, so there was no way the cluster could stay up with VMware starving it of CPU time like that.

Anyway, I tidied up that program ("am-i-scheduled") and packaged it for RHEL7; the binary is so simple that it will also run on Ubuntu unchanged. I suspect it will run almost anywhere.

If you run AWS EC2 servers or other cloud-hosted servers, you really want to install this. This is the most convenient way you can find out how much CPU time you aren't getting: if your virtual machine is co-located with another virtual machine that is being used for Bitcoin mining, or password cracking, or a deep learning problem, you might want to terminate and try again. With am-i-scheduled, you can detect this easily, and measure the impact you are experiencing.

Here's the source: https://bitbucket.org/solresol/am-i-scheduled and the binaries (including RPMs) can be downloaded from here: https://bitbucket.org/solresol/am-i-scheduled/downloads/