Should you rebuild your platform from scratch?

I run into a lot of startups and larger enterprises who are somewhere along the journey of rebuilding their platform from the ground up.

There is a narrow set of legitimate reasons why you'd want to do this. And there is a narrow set of ways to do it well.

However, in most cases, rebuilding your platform from scratch is a mistake.

Why?

Because platform rebuilds almost invariably result in some combination of the following...

• Engineers disappearing into a black hole for an indeterminant amount of time

• Blown out timeframes that never seem to end

• Building over-complicated tech that - when it finally ships - doesn't meet the needs of the customer

• A constant battle to try to add new features or fix bugs in the legacy system while simultaneously hitting feature-complete with the new system (a moving target!)

• Most importantly: Stalled value-creation for your customers

Instead - whenever possible - iterate your way to success. Break your product and platform down into small parts and improve each part one-by-one. Even of those iterations involve slightly larger refactoring projects of significant sub-systems. Do this in the order of "customer pain".

Finally, keep in mind that many engineers tend to push for re-writes. This is because it's often easier and more fun to start with a blank piece of paper than trying to live with legacy code while implementing an iterative improvement process. While this instinct is understandable, it can often be wrong for the product and the business. Pressure test this tendency hard.

Finally, as I said at the beginning - there are situations where rebuilding from scratch is necessary. That's a post for another day.

Comprehensive vs Comprehensible

When dealing with the tension between comprehensive and comprehensible, you want to bias towards comprehensible. If a casual observer can't understand it, then no amount of detail will matter.

You don't need AI for your bootstrapped MVP startup idea

Often times the magic you think you need in your MVP is just icing on the cake that you can defer to later. Build the basic version first. Often that means setting aside the Machine learning, AI, Crypto, AR, VR stuff, and making something simple and valuable for people.

Sometimes the entity your startup is disrupting is bad government

A lot of government regulation is ostensibly designed to preserve and protect the customer experience. The problem is, however, that regulation moves far too slowly, it can be corrupted by special interests, and enforcement is hard to scale. It often fails to live up to its intended promise.

Think of Uber. The medallion system and other regulatory conditions were ostensibly designed to protect riders from unsafe cars and unsafe drivers and from taxi companies flooding the streets with taxis. It failed. However, it created a number of unintended consequences and was ultimately hijacked by the taxi companies to create false scarcity and protect their business.

Uber‘s job was not to build a business that was respectful of regulation, but rather understand the original intent of regulation and create a technology framework that delivered an incredible customer experience - in a way that regulatory framework never could.

The regulatory system is now being forced to adapt.

Sometimes the entity your startup is disrupting is bad government.

Post Covid opportunity for Enterprises

If you’re a large enterprise - your post-covid, digital transformation opportunity is not to build a great app - it’s to rethink your business model and customer journey to be more scalable, sustainable, user-friendly and delightful. Typically that’s enabled by technology, but it requires a holistic and first principles approach.

How to burn your money

Think there are two ways to go with managing your startup burn.

1. Optimize for keeping the lights on as LONG as possible. Even if that means not hiring key people who can help you fast-track your success.

2. Hire key (effective) people and make things go as FAST as possible. Even if that shortens the runway.

The problem is that in both cases you spend all the money. but with option 1 you're ALSO spending opportunity cost. I.e. Someone else will come along and disrupt you before you have a chance to get properly situated in the market.

Don't listen to Sales and Engineering too much

Sacrilege/Trigger warning:

As a product leader, when developing the product strategy and roadmap: I am more interested in what Design and Product Marketing says than what Engineering and Sales have to say.

Why? Because...

Sales: I can't over-index on what 1 customer thinks they need. Specific customers can be important inputs, but they don't know how to build generalized product. They only understand their particular pain. If they had their way we would build features to solve everything going on in their organization. It's our job - as a product lead company designed to scale - to determine, implement, and encourage best practices that work across companies and industries.

Engineering: I can't over-index on how it works or what the technical limitations. Engineers are amazing partners and collaborators but their focus is on implementation details and development effort. It's our job - as a product lead company designed to scale - to look past what we think is possible and focus on what customers really need. In my experience - once challenged - engineers are wizards who can ultimately build anything that's asked of them.

In other words:

1. Don't ask customers (plural) what they want. Ask them what pain they feel.

2. Have an opinion about what you're building and what you are NOT building. This includes the best practices or ideal flows for solving problems in a first-principles, digital-first way.

3. Design something great.

4. Challenge your engineers to build it in small, digestible iterations.

In yet other words: LEAD!

Avoid advisor fatigue!

I bump into a lot of founders who are bewildered by all the contradictory advice they get.

Go b2b! Go Enterprise! Go b2c. Sell it for cheap! Sell it for a premium price! Grow! Scale! Revenue! Raise money! Don't raise money!!!!

Be careful about speaking to too many advisors - particularly random, one-off conversations.

Every advisor has their biases and knee-jerk instincts. It can really confuse you.

You need to pick 1 or 2 key people you trust and like. Together, you develop a long-term relationship. As a team, you will develop a single medium-term strategy. Then all the advice/tactics should be aligned with that strategy over a sustained period of time.

Investors are stupid

As a founder, you need to remember that compared to you, many investors are pretty stupid when it comes to your startup and your journey.

Why?

It could be for a number of different reasons. Including...

1. Many investors have never been operators. They don’t really know what it’s like.

2. Angels are distracted with their real life. It’s hard to get and keep their attention.

3. You have likely spent a lot more time thinking about the problem you’re working on and the market you’re targeting. If you’re doing it right - you’re the expert.

To compensate for this “stupidity” (and derisk their decisions) investors use 1 simple trick: Pattern matching.

They look for simple signals like “two founders” or “revenue”. So always remember:

1. Don’t get upset if they don’t get it. It’s your job to get and keep their attention. Then it’s your job to educate them.

2. Take their feedback with a grain of salt.

Go for growth!

I feel like I say this every few months. But let me say it again:

If your goal is to build a silicon valley style high- growth venture-backed startup, your primary goal is not revenue. It is growth. Period.

The formula for growth is simple (but not easy):

Build a product that people immediately fall in love with and continue to use for a long time.

Don’t obsess about charging them. Don’t try to force it down their throats through partnerships and b2b. Don’t make it too complicated to use and understand. Don’t spend forever building it; ship it and learn from actual user behavior.

Finally, if you are building a software-based startup and you are not aiming for global rapid growth, you are likely burning a lot of opportunity cost. The reason tech startups are interesting in the first place is because Software scales globally. Aim for scale. Change the world! If you don’t, someone else will. And they will likely disrupt you eventually.

Determining founder equity

If there’s a dispute about founding equity simply go back and revisit the story.

Determine everyone’s role getting the business to it’s current state and their intended participation moving forward.

There are standard equity positions for each role and each contribution based on industry best practices.

- Advisors get ~0-5% (depending on role and stage)

- Investors get ~20-30% per round

- Employees get ~2-3x their salary in options

- Operational/full time Cofounders get ~10-30% each (assuming 2-3 cofounders) 

No one should get 50/50 just ‘cause. #consultingconvos

Dealing with unprofessional colleagues

If someone is being unprofessional in your work interactions - particularly in group meetings - you must confront them about it 1:1.

You teach people how to treat you. If you tolerate disrespect you will continue to receive disrespect.

Schedule a meeting with the person and let them know that their behavior does not work for you. Encourage them to provide their feedback and concerns in a way that is constructive or in private.

If this doesn’t work, escalate to their manager. If that doesn’t work remove them from your meetings.

As a PM, how accountable are you for the success of the product and the business?

Both 10% and 90%.

The product is accountable 10% because while the product need to be amazing; sales, marketing, support, bizdev, finance, etc etc all need to align and do their part to inform, package and sell the product. A great product poorly sold can't succeed.

However, the product *function* (lead by the head of product) is accountable 90% because it's his or her job to drive alignment across all other functions. A great PM knows that building a great product requires great alignment across all internal and external stakeholders (i.e. the market).

Getting conviction

Team conviction ultimately doesn’t come from data. It comes from leadership.

Be more ambitious with your hiring.

Particularly at the beginning - but also throughout your company’s growth - your goal should not just be to add a but in the seat or a soldier to the army.

Aim to hire rockstars that raise the average quality/effectiveness of the team. If you’re the smartest person in the room you should be very uncomfortable.

If you think you’re company isn’t well-positioned to attract great talent - perhaps because the vision, mission, culture, or brand isn’t strong enough - then ask yourself why are you are content to work for something that wouldn’t excite rockstars?

Work on something great, and invite great people to help.

Combative vs. Collaborative work styles

In some older workplaces and workstyles, there is a tendency to assert authority and insist on certain outcomes using a combative and confrontational style.

This no longer works. In modern companies and work cultures, the goal is to create a collaborative and open environment whereby everyone is encouraged to express their perspective, concerns, and creative ideas freely.

In these environments, a leader's role is not to confront members of the team, but rather ask them questions that identify blind spots, flesh-out under-developed ideas and encourages everyone to do their best work

Rather than asking "Why didn't you...", the question should be "Why don't we...". Instead of saying "You totally missed the point..." the observation might be expressed "I think there's an area we need to explore more...". 

Importantly, this doesn't suggest that communication should be vague. It should be precise and actionable. It just doesn't need to make the other person feel like they're under attack.

Should the product team get involved in shaping technical architecture?

Should the product team get involved in shaping technical architecture?

In general, Product Managers (PMs) should not get too involved in making technical design decisions.

Instead, product managers can contribute by facilitating a conversation with engineering and engineering leadership around the following topics:

Principles

The PM would list the key non-functional requirements for the product. Each might imply a certain technical choice or approach. For example:

a) It must be possible for different teams and engineers to work on various parts of the system independently. This might imply a clear separation of concerns between various parts of the system.

b) We want to invent as little as possible. Instead, we want to prioritize time to market. This might imply the use of off-the-shelf cloud services or open source wherever possible.

c) We want to be able to hire from a large pool of engineers who have experience with our tech stack. Which might imply the use of popular tools rather than new, experimental tech.

d) We should know the moment something breaks or does not function as expected. Which might imply automated testing and alerting for every component.

Visibility

The PM should sit with the engineering team and walk them through the roadmap. While doing so, they should pay special attention to patterns that might repeat or features/requirements that may need to expand over time.

For example: "This concept of transforming data from X to Y happens a lot. You can see it here, here and here." or "Being able to connect to this address book for a list of user contacts is just the beginning. Over time we will want to give the user the option to connect to a wide range of 3rd party address books"

The former implies that a particular component might be generalized to handle lots of data transformations across the system. The latter implies that the address book importer will ultimately need to be designed to support multiple connectors and data types.

Time

Give engineers the time they need to do thoughtful technical designs, reviews and builds so that they can make more durable medium-term decisions. If everything is an emergency -working to a hard deadline - engineers will cut corners to get the job done for you.

Engineering reviews

Encourage the engineering team to have technical design review meetings with each other to pressure test proposed design decisions against the principles and roadmap.

Permission to refactor

Finally, remember it’s ok for engineering to refactor code later. Particularly early in a startups life where product-market fit is still a challenge. If they are not building just enough to make the user experience work well, then they risk over-engineering the solution and getting stuck building things for far too long instead of shipping new value to the market and iterating.

Collectively, this will all help the engineering team make great decisions without the product team getting too prescriptive. It will also help the engineering team avoid over-building sophisticated things that no one will use.

Product and Eng

Product and Eng shouldn’t be in separate “departments”. They should be in the same mission driven group solving problems together.

Should you hire remote workers?

The only thing more powerful than having a group of people in a room working on a problem is having the best people anywhere in the world working on that same problem. Virtual teams allow you to pick the best talent - wherever they may be.

Should your business focus on sustainability?

Short answer: Yes

Long answer: Yes because...

1. The environment will die without us all pulling our weight and improving the situation. Without the environment the economy (and your company) is dead

2. Green is often cheeper over the long term. Control the climate in your stores better with insulation to save on aircon. Solar energy installations pay for themselves long term etc etc

3. There is a large and growing base of customers who are prioritizing a) simplicity b) minimalism c) quality d) sustainability in their products and brands. They are increasingly finding their needs met by new, direct to consumer companies online. No stores, no fuss.

How can you tap into this new opportunity?

The twist is that all these new priorities are actually about sustainability.

Simplicity & minimalism is about doing more with less effort and less stuff. Quality is about buying things once and not having to throw it out and get a new one.

So, while developing your sustainability strategy, don’t forget that it’s about much more than just materials and process. It’s also about...

1. How your product or service is designed: Simple and easy to use.

2. How your product or service AND brand (often overlooked) looks and feels: Minimalist. Clean.

3. How your product or service is constructed: High quality build. Built to last. And finally and most obviously...

4. How your product or service is manufactured and delivered: Recycled materials. Second hand markerplace. Recyclability. Etc