success factors

Engineering and product should be unified, not separate

A CEO friend once asked me whether he should hire a Chief Product Officer in addition to his Chief Technology Officer. The CPO would hire a bunch of product managers, while the CTO would continue to manage engineers.

My response was that there shouldn’t be a separation. Making it two orgs would introduce a lot of unnecessary frustration and inefficiency.

Fence-chucking tremendously slows down joint problem solving

For those who follow this blog, you know how important these 2 rules are to designing highly productive organisations:

  1. The 80% rule: each team should be equipped with the resources and authority to deliver 80% of their mission without outside dependency
  2. Eliminate friction: eliminate friction to close the loop quickly over and over again

When Product is separate from Engineering, “fence chucking” often happens. This is when Product does a piece of work and then throws it over the fence to Engineering to carry on with it. It’s off of Product’s daily plate.

The issue is that making new things is not like running a production line. There is a lot of back-and-forth throughout the process – because it’s a new thing! E.g. something turns out to be harder than anticipated, someone misunderstood something, there’s an edge case no one thought of, etc.

But when key people are in separate orgs, there’s a fence between them: different incentives, schedules, priorities, working practices, lack of knowledge share. E.g. a 5 minute unblocking discussion might not happen for several hours. Or what comes out of the build doesn’t actually solve the root issue. Or technical debt and maintenance issues go unaddressed. Or a product manager doesn’t understand the full implications of their design choice.

Sometimes in a company, fence chucking is unavoidable. But by separating Product and Engineering, you introduce fence chucking unnecessarily.

Hats first, job titles second

Forget about job titles and org structure for a moment. Just think about hats. A “hat” is a bunch of tasks that need to get repeatedly done.

Think about all the hats that need to be worn to build a market leading product. So for example, your company might have the following hats:

  • Prioritisation: look at range of things we could be building + talk to sales and ops + do analysis = figure out what’s most important right now
  • Sprint management: setup schedulers + keep tracking tool uncluttered
  • Product design: really understand issue + brainstorm options + iterate on options + early wireframing + quick investigations = written design document
  • Technical design: really understand issue + understand product design + design database models + design architecture = technical design points added to design doc
  • Technical build: really understand issue + understand design + write code + write & run tests + review with colleagues = branch ready for release
  • Etc.

There are a lot of hats. An effective team will wear most of those hats within itself (again, the 80% Rule!). However, 12 hats does not mean needing 12 people. 1 person usually wears multiple hats. And 1 hat could be shared by multiple people. It’ll vary depending on what makes your company special.

At the end of this, you might say that Sarah wears Hats A+B+E. And Jimmy wears hats B+C+D. Etc. You can then put a job title on that combination of hats.

But the title almost doesn’t matter. What does matter is that a) all needed hats are competently worn and b) these people are working directly with each other (rather than over a fence).

Don’t split “Product” and “Engineering”

For the question of Product vs Engineering, the hat exercise shows that they should be the same org, a unified team. For companies that have only an “Engineering” or “Tech” team delivering their product, that team is already a unified product development organisation. So when CEOs look at “adding” a product org, they’re actually looking at splitting out Product.

The question of making Product into a separate entity typically comes up because there is a “hat gap”. E.g. prioritisation sucks (e.g. random people ask developers to build something haphazardly). Or product design is weak (e.g. the solution is confusing, over-engineered, etc). Or tech leadership needs help to be more commercially minded.

If there is a gap, typically the best way to solve it is to:
a) ask existing people to wear the missing hats (if they have time, inclination and incentives)
b) hire someone to wear the missing hats (and incorporate them into the existing org)
c) change out the existing people (painful but sometimes the right answer)

Not spin up a separate department within the company!

The little unsexy things get done

A notable benefit of having unified teams is that it is simpler to get little unsexy things done. Examples are:

  • Technical debt and maintenance: e.g. upgrading out-of-date software packages, doing a “proper” fix for that nasty bug solved last week, refactoring a chunk of code, etc.
  • Efficiency improvements: implementing new tools and/or changing practices that help the team be more efficient
  • DevOps improvements: e.g. building better reports and alerts for monitoring
  • Small bugs and tweaks: minor improvements (e.g. tightening up the UI, tweaking copy on a page, etc) that generally take less than hour to do

When Product and Engineering are separate, the little unsexy things don’t get done typically because:

  1. Clash of incentives: Product is normally rewarded for delivering new functionality; not behind-the-scenes improvements. Therefore they will never prioritise these items
  2. Overhead of fence chucking: because it takes a non-trivial amount of effort to push an item over the fence, it’s not worth it for minor improvements

Cumulatively, not doing these items adds up to significant drag. Teams move slower, catastrophic errors get made, user trust declines, etc. So aside from eliminating fences, unifying teams result in better nuanced decisions.

Mindsets matter

To some people, unified teams is scary. Working with someone in a cross-functional team means knowing something about what they do (and vice-versa). E.g. a product manager should know something about database models, so that they can understand why the original product design won’t work with the current database.

It means stretching out of your area of expertise – and thinking more holistically. That stretch may differ from team-to-team or from year-to-year. It requires being honest about what you don’t know and enjoying learning new things.

Without teammates who are willing to embrace it, a unified approach won’t work.

It isn’t easy but it’s worth figuring out

I get why a CEO might bolt on a CPO and product org. For the CEO, it’s a straightforward way to fill a gap. And if the existing org isn’t able to adapt, it might be the only option. But it’s like buying 10 kilogram running shoes. Sure you can run the race. But you’ll never win it.

Organising around purpose (rather than function) and ensuring that the teams are reasonably complete is harder in the short-term. But in the face of serious long-term competition, it gives you a chance at winning.

GS Dun works on developing new ventures. The name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.

The key to product development capability is eliminating friction from development loops

I think about product development capability a lot. It started in earnest when I left Betfair (a well-resourced company) to bootstrap my own startup (a very poorly resourced company). The contrast and shock meant that I had to think pretty critically about how I did things. And that critical thinking continued as I launched other things and worked across a mix of startup and corporates.

So what makes an organisation good at developing product? Brainstorm it and you’ll come up with 101 things: people, processes, tools, culture and so on. We could write a pretty long list – and that list would largely differ for each company and each product.

However, I think there is one key insight that applies regardless of what kind of company you are and what you’re building.

To have great product development capability, close the loop quickly and well. Over and over again.

Let me explain. When I talk about “loops”, I’m referring to development loops. It’s a cycle where you start with prioritisation, then you design, then you build – and then you evaluate. Anyone who’s heard of agile will be familiar with this idea. It’s common place. It’s even mundane.

The nuance here is the importance of this loop. The loop is key. Or rather, how fast and well you close this loop repeatedly is key. Closing the loop isn’t just one of many aspects of your product capability. It is your capability.

Do a shit job of prioritisation? You’re screwed. Skip designing and jump straight to build? Trouble. Not actually looking at the data to see your results? Goodbye. Holding back a release until you think it’s perfect? Not great.

What makes the loop so important is that each loop is a shot-on-goal. Given that product development is an uncertain process of discovery, you need a lot of shots. If you run out of them, it’s over. So you need to close the loop fast (and do it well!).

Eliminate friction to get more shots on goal

When I think about improving loops, I think about eliminating friction. Friction can come from a lot of sources. Here are some examples I’ve seen:

  • The development team had no ability to release. A separate team handled it, so something as simple as a bug fix would wait for days (even over a week) to be released
  • Prioritization was done by committee, which often can’t really decide, so decisions get delayed
  • The team didn’t have the authority or knowledge to course correct, so when problems emerged, they got stuck until they could meet with the right person
  • Meetings and processes were ad hoc, requiring a lot of scheduling coordination
  • The people seeing the results are totally separate from the team
  • There aren’t any easy mechanisms for data and feedback, so evaluation only happens once a quarter
  • Teammates not liking / respecting / trusting each other
  • Someone in the company (legal, security, etc) decides that they need to approve everything before it goes out – and they take their time with it

In other words, friction in loops basically comes from disconnect between people and a lack of authority within the team.

The friction-free checklist

How do you know if you have any major sources of friction? I’d start by talking to the members of the team. How often and when do they feel frustrated? Confused?

Aside from asking the team, here’s a checklist that might help. Think of it as a guide, not a definitive scorecard.

  • Agile methodology? The point here is that the team shouldn’t be burning up time scheduling meetings and figuring out deadlines. It just happens. There’s an automatic rhythm to how this operates.
  • Clear prioritization maker? This can’t be a committee. It has to be a person. And this person has to be very accessible. This person also should not be a process manager, because one can’t prioritize quickly and well without content knowledge
  • Self-contained, functionally complete team? This is my 80% rule for organisations. For a team to meet its responsibilities, it needs authority over at least 80% of the resources needed to make it happen.
  • Autonomy to design and build? The team should be given the problem to solve and the knowledge behind it, so they can design-and-build a solution. If they’re instead being given specific specs (“Make this font bigger”), then it’s going to end up with a lot more back-and-forth before getting to a good result.
  • Frustration-free tools? If the team regularly swears at their tools, then change the tools. This is why I’m a big fan of letting teams choose their own tech and equipment as much as possible (and why it’s a terrible idea to save a couple hundred bucks by getting inferior kit).

Again, this checklist is just a guide. But use it as a starting point, in addition to an honest conversation with the team, to help you build some kick-ass product development capability.

GS Dun is a product management consultancy. How to build ’em. How to grow ’em. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.

The next time you’re in a meeting where someone is throwing out some seemingly spurious results, try our hack-y AB test calculator, cakeAB. Mobile friendly, just punch in the numbers and get a steer on whether there really is a difference between those 2 campaigns. www.cakeab.com

 

To beat the odds in ramen, think like an engineer

Singapore is a not an easy place to start a food business. With thousands of hawker stalls selling delicious dishes for just a handful of dollars, convincing someone to spend SGD$16 for a bowl of noodles at lunchtime is not the easiest sell.

But Chris Tan and his partners at Buta Ramen have done exactly that. And they’ve been recognized as the number one ramen place in Singapore and kept it going for 3 years now.

But how have they succeeded in such an intensely competitive environment?

By thinking like engineers. With backgrounds in engineering, the team thought about their venture differently from most food entrepreneurs. I spoke to Chris when I was in Singapore and learned their story.

Fit the concept to the location.

A typical food business story is to start with a concept and then find a location.

Chris and his partners aren’t typical. They did it the other way around. They first found a high foot-traffic location in the heart of the Central Business District. Then they decided on ramen, served with tasty pork.

Why ramen with pork? They had a passion for great meat. And it was unique compared to other eateries in the area (sandwiches, Italian and other Mediterranean fare).

But most importantly, ramen could be done in the very limited square footage they secured.

Demand is spiky, so keep dishes moving fast.

The hot food business has very spiky demand. A huge chunk of your business comes in at mealtime hours. So it’s important that when that demand hits, you put out dishes quickly.

Part of the solution is inherent to ramen. It’s a dish that allows for ingredients to be prepped ahead of time. A good bowl of ramen needs minimal food prep once the customer has ordered.

But a less obvious part of this is before the order even comes in. It’s menu simplicity. Like a good user interface, the Buta menu doesn’t flood you with choices. It gives you four dishes. That’s it.

First, this makes customer decision making faster. It is far less likely that someone gets to the front of the line and is still stuck in indecision.

And second, a simple menu means fast prep time. Only a certain set of ingredients are needed and there is only so much complexity that the chefs need to handle. When under time pressure, it makes a difference.

Don’t sacrifice quality for speed.

Let’s be clear. Buta Ramen is not a McDonald’s factory, sacrificing quality for the sake of high speed production.

Like good engineers optimizing an outcome given constraints, the Buta Ramen team worked within the constraint of maintaining high quality food. The meat marinates for 24 hours overnight. They conduct egg cooking experiments to perfect their technique . They go to conferences to see what else is cooking (figuratively and literally).

Quality product is the ticket to play. The efficiency is what gets you profit.

Brilliant buzz marketing beats buying ads.

Buying ads is a terrible way to market a hot food business. Instead, the Buta team capitalized on the fact that the business lunchtime crowd is a repetitive one. Office workers tend to go to the same area each day at lunchtime. So they went ahead and created lines out the door on day 1.

How? They gave away meals for free. Full size portions of ramen (not skimpy sample sizes). This created a ridiculous queue. And because they were running out, they handed out tickets to everyone in line who missed a free meal, so they’d come back the next day.

For every office worker who dashed out those days to grab their usual lunch, just seeing the ridiculous queues ensured they made a mental note to stop by.

Think different.

Having spent time in the food sector, I can safely say that the Buta team is not typical – hence a large part of why they’ve been able to beat the odds in an intensely competitive sector. If you’re in Singapore, drop by. And if you’re not local, then here’s something to salivate over.

GS Dun builds new ventures and products, such as CakeAB, the easy-to-use pocket calculator for AB tests. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.

 

 

Six easy pieces: the essentials of setting up a new venture

Once again, pretend you’re the CEO of an established company. You want to launch a high-risk, high-reward business. Maybe it’s based on a new product. Or entry into a new country or region. Whatever it is, how should you set it up?

Here’s my simplified “six easy pieces” (the title is an homage to Richard Feynman):

  1. Pick “founder(s)”
  2. Give them autonomy, not dependency
  3. Let them handpick a couple of your people
  4. Tell your existing teams to have an open door, but they don’t call the shots
  5. Kick the new venture team physically out the door
  6. Establish some rules for governance

Let me explain each of these in a bit more detail.

1. Pick founder(s)

Of course, you need founder(s) who will have the right mix of vision, specialist skills and general management talent to push it forward. But in a new ventures context, it’s important to have founder(s) who will identify with the venture, and not feel like they are still just employees of your company (the “mothership”). They should feel like the venture is their baby and be irrationally passionate about it.

2. Give them autonomy, not dependency

It’s common for the mothership to make promises to the new venture. “We’ll do your product, your operations, your X, your Y, etc. You don’t need much cash. We’re being really efficient!”

This is a recipe for slow death – or in the best case scenario, a huge amount of middle management discussions. “Efficiency” often ends up meaning shared resource pools in which the new venture has to compete against mothership teams. It will lose. Losing means bottlenecks and loss of agility. And loss of agility for a new venture is death.

At one venture I worked on, environments were controlled by a shared infrastructure team. Our releases would sit on the shelf for weeks, because mothership business units always ended up taking priority for release slots. We were about as agile as a block of wood.

For any critical aspect of its business, the new venture team must be free of dependency on the mothership. So rather than giving them shared resources, give them:

  1. Cash! Enough budget to be a standalone entity. If it makes sense to get something from a mothership team, then it can use the cash to buy that in.
  2. The autonomy to solve their needs in whatever way they see fit. If the mothership team doesn’t deliver what’s needed, the new venture team needs to be free to solve it another way: hire its own team, find an external partner or supplier, etc.

3. Let them handpick a couple of your people

The new venture should have a couple of your best people because a) existing expertise is how your new venture can beat others and b) the new venture needs strong informal relationships into the mothership organisation at multiple levels. Let the new venture handpick at least a junior level superstar with a couple years in the mothership.

A high-performing graduate once joined my new venture team, after he had about a year of experience. Not only was he an excellent marketer, he knew every back door for getting something done with different teams in the mothership, because he knew the other graduates in the company. And for him, it was a great development opportunity to dive into the deep-end.

The team that loses the superstar will probably protest. They will feel pain. But for them it’s not a matter of life-or-death. And let’s face it: high-performers need new challenges to stay.

4. Tell your existing teams to have an open door, but they don’t call the shots

You want your new venture to be able to use the mothership as a competitive advantage. But you don’t want to kill its agility.

You achieve this balance by establishing some clear ground rules for the new venture and mothership teams.

  1. The mothership teams should have an open door for advice. Good advice is easy to give and immensely valuable to receive. If the new venture wants a few hours or even a day, give it to them.
  2. The mothership teams should be open to selling services into the new venture. If the new venture needs something from a mothership team, they should negotiate a commercial agreement. An explicit agreement sets expectations and allocate resources to fulfill those expectations. Just as importantly, it takes relatively little management time. The alternative is constant lobbying, which easily turns into a full time job for managers.
  3. The mothership teams don’t call the shots. The head of marketing does not get to determine the marketing plan for the new venture. The UX specialist does not get to sign off on the design of the next feature. This kind of “control creep” means the new venture becomes as agile as a block of wood.

5. Kick the new venture team physically out the door

Out-of-sight is out-of-mind. And this can be a good thing. By their very nature, new ventures are doing something different. And these differences will easily trigger seemingly minor, but very disruptive questions and comments from mothership people. “Why this brand positioning… This feature seems strange… My son thinks we should do XYZ differently…”

The new venture team knows the importance of keeping people onside, so it will stop and reply. And stop to take meetings to explain. And after a while, the hours turn into real management overhead and a subtle pressure to avoid doing things too differently.

The ideal solution is to get an office down the road. Close enough for new ventures and mothership people to meet for a coffee when needed. But far enough that the new venture isn’t disrupted by “parachute management”. It also fosters the tight-knit bonds and culture needed to become a high-performing team.

6. Establish some rules for governance

The mothership needs to maintain some form of oversight of the new venture and its management team. The trick is doing it without imposing unnecessary overhead.

In one example, the new venture has a board made up of senior level execs and its clear what kind of decisions need to be taken at the board level. This is clean and straightforward as a form of governance.

In another example, the new venture is effectively subject to the control of different teams and managers: finance, audit, HR, security, etc. Often these managers are aiming to minimize downside risk, rather than capture upside. This type of control makes sense for an established company like the mothership. But for a new venture, it just reduces agility.

Conclusion: set up the new venture to maximize agility

If you’ve read this far, you can probably tell that I’m a big believer in agility. For a high-risk, high-reward business like a new venture, rapidly experimenting and responding to new insights and events is the lifeblood of finding success. And large organizations tend to be terrible at agility. So as the CEO of the mothership, when setting up a new venture, think about how to keep the management overhead down and the talent up. In other words, maximize agility.

Org for new ventures matters. A lot.

Imagine you’re the CEO of a large established business. You’re considering launching a new venture based on Product X. It’s risky, but it could be the key to future growth. So what would you think about?

You might focus on the product and service. Is it innovative enough? Do customers want it? Or you might focus on the business case. What’s the forecast? Scenarios? Investment level?

But among these questions, the one that is usually under-considered is organization. And yet it may be more critical than the other questions being debated.

This might be surprising for anyone that knows me. I’m not traditionally an “organization guy”. My background is in strategy, insight and product. But having worked on a range of new ventures and startups, I’ve seen organization come up time-and-time again, as a critical factor. It determines team cohesion, velocity and agility.

“Organization” in this context means a few things, such as:

  • The talent working directly on the new venture
  • How the new venture team works with others at the wider company (both for execution and oversight purposes)
  • The culture of both the parent company and the new venture

To put it into perspective, just look at the startup world. Early stage investors focus very heavily on the team. Who are they? What’s their track record? Do they together form an effective team? The opportunity and plan could be “right”, but investors will back out if the team is wrong.

The org question for new ventures is even more complex than it is for startups, because it involves two entities. And the consequences of the org question are greater. Getting it right means having the best of both worlds: startup agility and large company resources. Getting it wrong means being another failed venture, crippled by bureaucracy and large company indecision.

In future postings, I plan on sharing thoughts on these org questions in more detail.

But for now, if you’re a C-level exec thinking about launching that new thing, ask yourself if you’re focusing on the org question at least as much as an early stage investor focusing on a startup team. If not, the venture may be handicapped before it even gets off the ground.