Product & Startup Builder

Slowing down to go faster + marketplaces

Added on by Chris Saad.

In rapidly growing teams there’s often - if you’re lucky - a proposal that inevitably gets floated when the chaos and confusion becomes too much:

It’s often referred to as “slowing down to go faster”

This principle applies to all business types and product types but it is particularly important in the context of a marketplace where you often want to do fewer, more standardized things so you can scale.

Here are some thoughts I’ve recently had on the subject - specifically for a marketplace business:

—-

I love the concept of “slowing down to go faster” when it comes to product.

I love it so much that I’d describe it more broadly and apply it across the whole company.

More broadly it’s really about..

“Structuring and standardizing everything so a company can achieve rapid growth, scale and liquidity in its marketplace”

(JFYI liquidity means the number and ease of transactions between the participants in a marketplace. This is a measure of its success and what makes it an unstoppable business model)

This requires that - across the business - the team pause for a moment on tactics to get broad consensus on principles, patterns, programs and templates so that we can

A) push responsibility and accountability out to the edges of a rapidly growing team while

B ) still ensuring that the team can act in alignment, execute in repeatable high-scale ways and make the right decisions without excessive meetings or additional ad-Hoc work

For product this means getting consensus on…

- Problems being solved (and roughly what order)

- Products being built for each problem

- Product principles

- Product taxonomy/vocabulary

- Ways the team will be organized behind each products (ideal org chart)

- Ways of working/responsibilities for each role/group in the team

- A mid-fidelity end-to-end idealized UX so that everyone understands the shape of what‘a being built

- Decomposing the idealized UX into A roadmap of Broad themes/milestones for the product (rather than prioritizing features)

- Getting 2-3 milestones of the roadmap fully spec’d out (inc high fidelity mocks) in a way that covers all the product principles

- Execute and stay ahead of the milestone curve

This process broadly applies to other operational aspects of the business such as partnerships and support. They all need to act this way so that every part of the business can scale at the same rate.

Obviously when applied to other parts of the business, some of the details of consensus change.

For example, for partnerships, replace the word product with partnership to create partnership taxonomy/levers and partnership principles. Replace the roadmap with a prioritized partner target list. Replace the idealized product design with idealized template agreements that are clear but flexible so that everyone understands the shape of the deals we want to create. This would look like this..

- A standard list of Partnership types the business needs (and roughly what order)

- Standardized Engagement Types the business will allow

- Partnership principles

- Partnership taxonomy/vocabulary

- Ways we’re organizing the team behind these partnerships

- Ways of working/responsibilities for each role

- Ideal template agreements for each partner type and engagement that is flexible and clear and communicates the shape of this kind of engagement

- A pipeline/hit list for each partner type

- Start placing each new discussion within this framework

- Execute and stay ahead of the milestone curve

The nice bonus is that standardizing something like partnerships and support reduces complexity in the product and drives a consistent user experience in marketplace. That in turn drives more liquidity.

Final note: many companies have a version of many of these things. But the devil is in the details. They need to be reviewed and taken to the next level.

Also, once they are roughly right, it’s essential that the whole team is briefed of this consensus and starts to act in accordance with it even while leaders are not in the room.

I.e. It needs to be in the water and inform all behaviorS