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:

The 80% rule: each team should be equipped with the resources and authority to deliver 80% of their mission without outside dependency
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:

Clash of incentives: Product is normally rewarded for delivering new functionality; not behind-the-scenes improvements. Therefore they will never prioritise these items
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.

Product Development

Brutal prioritisation: how small product teams can get a lot done

Over the years of working on different ventures, I’ve been able to get a lot done with little resource. A big part of that has been the good fortune of working with talented people.

The other big part is “brutal prioritisation”. I once wrote that the fundamental job of a product manager is to prioritise. Brutal prioritisation (BP) is the extreme version of this.

Why is it brutal?

The “brutality” of this prioritisation is that you’re not just rejecting bad ideas. You’re rejecting good ones too. In other words, you’re working on only the highest value items and making good (but less valuable) items wait.

The other reason it’s brutal is because of speed and uncertainty. You’re making these decisions fast and over-and-over again, each day, sprint and year. You don’t have perfect information. You’re taking risk (and managing it). And you’re not kicking the decision to a committee, thereby delaying everything.

Why would you ever reject a good idea?

Because you’re severely resource constrained. Demand always outstrips supply. But when you’re in a new ambitious venture, that imbalance is much more severe. Saying “yes” to anything that is a good idea implicitly means saying “no” randomly to something else. That’s the reality of finite time and talent.

So instead of saying “no” haphazardly, be deliberate. It’s not enough to be a good idea. It has to be one of the highest value ideas at the time.

As an example, a common conundrum for an ambitious company is deciding whether to build for new customers or existing customers. Both are good ideas. But if you don’t have the resource, then you need to be deliberate about which ones get a “yes” or a “no”.

Keep in mind that saying “no” doesn’t necessarily mean “never”. It just means “not now”. It goes in the backlog. And chances are, some version of it will eventually get done, when the time is right.

How do you make brutal prioritisation decisions?

With a lot of difficulty. Just kidding. Seriously, you need two pieces:

Clarity of your top goals
Strong understanding of the drivers

Clear goal priority is pretty self-explanatory. What’s the company trying to do? What’s your team aiming for? If it’s unclear, then figuring this out is your top priority goal.

Strong understanding of drivers means that you need to know a) what will “move the needle” towards your goal and b) how much. Anyone can come up with (a). Most people fail at (b). Most people could tell you the 12 items that help with the goal. Only the talented ones could point to the 2 that will deliver 80% of the outcome.

Knowing “how much?” is hard. It comes from a combination of analytics, customer research, deep experience, etc. Most of all, it comes from having a detailed mind and problem solving power. The people who fail at (b) do so because they miss key details or can’t integrate disparate pieces of information.

Your organisation has to buy into this

Your organisation needs to entrust you (or you plus one other key person like the CEO) to make swift, brutal decisions, which may not always be popular. Your organisation needs to also understand that many times a good item will get a “no” (because it doesn’t move the needle on the top priority and you don’t have the resources to pursue it simultaneously).

If your organisation doesn’t trust you, you end up with product-management-by-committee. It’s costly. “I need control over what gets done.” “I need to be consulted before something is released.” “I want dates for when my stuff will be done.” “My idea is great. Justify why it’s not being worked on now.”

Doing it this way takes serious resource. To put it more simply, if people want it, then the organisation needs to at least double the team (and slow down delivery). This isn’t an exaggeration. It goes a long way to explaining how small companies run circles around giant corporates, despite the apparent inequality in resources.

I’m not advocating a total absence of internal communication or co-operation. But a product manager should be spending the vast majority of their time on users, insight, design and development. Not slides, emails and meetings for internal stakeholders.

One other way to screw up brutal prioritisation is to have far too little resource. While BP allows you to do a lot more with relatively little, it isn’t magic. While you don’t need fat, you still need muscle. Otherwise you’re just a pile of bones.

Why not just hire more people?

If the company is doing well and you find yourself saying “no” a lot, why not just go add more people? It’s a fair question. The considerations are:

Finding good people is hard and adding lots of them very quickly may break a team
Brutal prioritisation forces the company to only serve needs, not whims

The last one needs some explanation. A lot of times, people internally will ask for something. “In my last meeting, the customer said we should totally make the button green and the text bigger.” This is a whim. It’s knee jerk. It’s badly understood. They aren’t harmless. Because they’re badly thought out, they often knock back or break the product elsewhere, requiring more work to fix.

In an undisciplined organisation, having a bigger team means doing more whims (rather than real needs). In other words, if you haven’t figured out how to prioritise well with a small team, having a larger team isn’t going to teach you.

Be smart + move fast

I previously wrote about how product orgs need to close their development loops quickly. Brutal prioritisation is basically an extension of this concept. You need to be smart (about your goals and drivers) and organisationally be setup to enable you to move fast. Doing this means you can outperform other teams and punch well above your weight.

GS Dun provides leadership for new ventures. When you’re at an inflection point and need to do something different, we help. 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.

Product Development success factors The 80% Rule

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

Product Development

The Ultimate Crash Course in product management

The last post was about what a product manager actually does. This post attempts to answer a question I often get asked: how to become a product manager? My simple answer is:

Build and grow a product.

It’s a facetious answer because generally the person asking really just wants to know about the CV side of things. How do I position myself? How do I get an interview?

But it’s a genuinely more useful answer, because it equips you to do the job.

Product management requires trade-offs across many disciplines

The last post talks about how product management is a multi-functional job. You need to at least be passably decent across a number of fields (technical, design, analysis, etc).

But there is one skill you need to become an expert at: integrating those fields to make prioritization decisions. This is the fundamental thing that a product manager does. And it’s really hard to develop that skill without being in an inherently cross-functional role.

The crash course approach is relatively time efficient because it forces you to quickly develop both your understanding of different disciplines and how to integrate them.

The crash course is very painful – but not impossible

Realistically, I don’t expect many people to be able to do this approach. It’s extremely painful – which puts the “crash” in the course.

The pain is from running up multiple learning curves, which means falling flat on one’s face many times from making mistakes. But if you’re one of the few that have the time, energy and self-awareness to make good from your mistakes, you’ll come out of this with a rare set of skills.

From a resource standpoint, doing a product on your own might seem impossible. But at least for digital products, the cost of building and launching something modest is within the scope of a single person. Possibly the same could be said for hardware products too (I’m less familiar with that world).

Keep in mind that there is no expectation here to build the next Facebook. And in fact, there’s no expectation that your product will become very big. But by the time you know, you’ll have much of the learnings anyway.

Again, it’s painful, especially if you’re doing this as an after-hours or weekend project. But it’s doable.

Some tips

If you’re diving head first into the deep-end, here are several tips to think about.

Pick a personal itch. It’ll save you time and minimize the risk that you go wrong by not understanding your user well enough.
Pick a small scope. Building a self-flying AI jetpack to cut your commute time is not realistic.
If you have zero technical ability, just pause right here and get some. Learning to code is easier than ever before. Run through tutorials, tinker, explore. Again you don’t need to become an expert, but understand just enough.
Design is much harder than it looks. Product design isn’t just aesthetics. It’s how well the product fulfils the user’s goal. If you’ve never paid much attention to design, then start by really noticing when and why you are delighted – or annoyed – by different products.
Process matters. Tools matter. But the tail should never wag the dog. Process and tools are there to multiply your productivity. If you’re spending more than 5-10% of your time on process, it’s too much. Scrum is my favourite. But whatever you use, tweak it to make it work for you.
Get to “real users in real situations” as quickly as possible. For example, take just a couple hours to draw some mockups and shove them in front of potential users for feedback (my favourite tool: Balsamiq). It truly sucks when you get feedback after months of work and realise how much of your time was wasted.
Tap into your network for help and advice. Have a friend who can teach you a bit? Great – hit them up for coffee. It’s a fast way to learn.
The crash course doesn’t really cover working with other people. So team up with someone if you can. But at the very least, make sure you’re learning how to work in a team elsewhere in your life.
The crash course will not suddenly make you an expert overnight. It is just a brutally fast way of accelerating your learning.

Build AND grow

Launching something is just the start. The real learning comes from trying to make something grow.

Product development is an iterative process (design –> build –> feedback). Before the initial release, the loop is a bit stunted, because the feedback is only from approximations of “real users in real situations” (RURS). The decision making is also much simpler in closed conditions.

When something is released, and you’re trying to grow it, you have to make decisions in the context of RURS. In other words, you’re operating in the real world. That entails a lot more complexity and challenge. This week, are you better off fixing that bug affecting your most vocal user – or finally launching that new feature?

Also pushing growth brings in a bunch of skills not involved during the pre-release phase. Things like basic analytics, user insights, marketing, investigating bugs, etc. Again, it’s a lot more complex when you’re trying to grow.

Just one tip about the growth. It’s easy to get caught up on big numbers and the distant future. Instead set yourself baby steps. Get 1 user. Then get 10 users. Then get 100. You’ll probably find just getting to 10 is a big challenge. But it will focus your prioritisation in very concrete and tactical ways, which is very important when you have limited resources.

There’s gotta be an easier way to get the skills of a product manager

Yup, there is. By no means is the crash course the only way to learn the job.

If you can land a job directly doing it (perhaps a large corporate that has an in-house program for it), then that’s fairly straightforward. Or you can specialise in any number of disciplines and then step your way towards it. In other words, look for cross-functional opportunities to work closely with “makers”. And then eventually pivot into other disciplines or into product management itself.

Regardless of how you chart your career path, the point of all of this is that on the skills front, make sure you become 1) at least passably decent across a range of disciplines and 2) you become excellent at integrating disciplines. With those two requirements fulfilled, you’ll have the foundation for being a strong product manager.

Product Development

What does a product manager do?

Through numerous conversations, I’ve found product management to be an area that confuses people. So this blog post (and probably the few following it) will be an attempt to shine more light onto product management. Think of it as Product Management 101.

So the first lesson is on “What does a product manager actually do?”

There are a few different answers floating around. A popular one is:

The product manager decides what to build (while the engineering team decides how to build it).

While I like this definition, it’s a bit too simple. I like it because the PM does decide what to build. But it’s too simple because it implies that the PM is at arms length from the engineers (which is outdated).

The essence of product management is to prioritize

I would say that the heart of what a product manager does is prioritize. A product manager does a lot of very different tasks and draws on a lot of different skills. But ultimately all of that feeds into what does the team design and build next? Do we fix that bug? Do we tweak that feature? Or do we launch a whole new feature?

Once you strip away all of the noise, the product manager fundamentally decides what’s next. This might be on a grand scale, i.e. over the course of the year. But it’s actually just as important that they do it on a micro scale, i.e. every day.

Product management is a multi-functional field

Saying that the essence of product management is prioritization makes it sound easy. It isn’t. It’s not a matter of sitting around and putting a list of 20 items in a sequence.

To do that prioritization well, a product manager should be pretty good at understanding a number of key inputs:

Commercial strategy
Analytics
Design – user experience, graphic, aesthetic, etc.
Technical knowledge
User research
Sales and marketing
Operations
Talents and skills of individual team members
Project and process management

In other words, what makes prioritization so hard is that the PM has to constantly compare apples and oranges (or more like bowls of mixed fruit) and decide which of them should be done next.

Is fixing a bug that only affects the single biggest customer more urgent than a feature that improves the long-term retention rate by 3%? Are there other ways that we can break down this work, so the choice doesn’t have to be so stark? Is the first iteration of the design good enough or should you delay the next piece of work to do another iteration?

You don’t have to be good at all of it

Too often PMs are used in organizations as glorified project managers, order takers or cost-benefit analysts. That’s a terrible misuse of the PM role. A PM’s skill set should be more diverse than that.

A good PM needs to be able to hold their own in each of the above disciplines. They won’t be the good at all of them. They’ll be great at couple, good at a few and just passably decent in the rest. But the point is that even in the areas that they just pass, they’ll know enough to ask the right questions.

What about vision?

Some might say that the PM should be the guardian of the vision, that inspiration for building what we build, the guiding light. I think a PM could be the guardian of the vision, but it’s not a necessary part of their job. When I think about startups, the CEO or founders will often be the guardian of the vision. The PM should understand it. But they don’t need to own it if someone else does.

organization Product Development

How to settle fights for development time

With development, demand always exceeds supply

A founder friend now runs a tech company approaching about 100 employees. It’s just big enough to have different departments: different business units, marketing, operations, customer service, etc. And like any tech company, there is a scarce amount of product development time.

With so many departments, how to allocate dev time?

The question my founder friend put to me was: how do we allocate development time?

It’s a major issue for any tech company that is big enough to have multiple departments. Companies will typically start to feel this pain at about something like 20 employees. And it magnifies with growth.

Don’t hold arm wrestling matches

The typical approach is to have a meeting every week or two where representatives from each department come together. Each person argues their case.

This becomes a series of arm wrestling matches. Essentially Person A has to out-argue Person B to get their work done.

This is a crappy of way of getting development decisions made.

The judge (a product manager, a C-level decision maker or a committee) cannot understand the minutiae well enough to weigh up a Small-Change-for-Marketing vs Medium-sized-Feature-for-Operations
A boatload of effort goes into lobbying each other, rather than solving actual problems for the business. It’s unproductive
Small-but-impactful work doesn’t get done. Experienced product people know the crazy value that can come from making small changes. But small changes don’t sell as well as dramatic features and changes

How to do it better?

Allocate entire sprints to different departments, not many small chunks of time

At the start of every quarter, the management team should simply allocate sprints to the different departments. Essentially they make a macro investment decision and not get stuck into the minutiae of every feature request.

For example, pretend the big aim this quarter is to boost customer acquisition. With single dev team running 2 week sprints, in a quarter, you have about 6 sprints to play with.

Your big decision: of the 6 sprints, how much goes to each department? For example:

3 sprints (1/3rd of the total amount) goes to marketing, since they’re going to be driving customer acquisition
2 sprints goes to operations and customer service who likely need some upgraded tools to serve a large inflow of new customers
1 goes to paying down tech debt and re-factoring systems that have been on the verge of collapsing

The management team should also set a schedule for the quarter, so each department can see when their sprints are coming up.

By doing this resource allocation decision at a macro-level once a quarter, the management team eliminates the arm wrestling that would otherwise happen over every single bit of dev work.

Let each department decide what to do with their sprints

Another key element of this approach is that each department can decide what to do with their sprints. Some teams will fill them with a host of small fixes and changes (anyone who has a run a back-office ops function will probably understand this). Others will go for major features.

When sprints are being allocated, a department may give an idea of how they would spend their budget. But they shouldn’t be beholden to it. Plans change. Shit happens. Each department lead will know at the time their biggest priorities.

Support each department lead with a solid product manager

Different department leads will have different levels of tech and product savviness. The product managers at the company need to work with department leads to refine their priorities. This has to be done ahead of their sprints.

By the time the department’s sprint is due to start, a product manager should have worked with the department to figure out what they need to have designed and built. This means understanding the department’s area of the business, stress testing priorities, getting rough sizing of effort involved, figuring out if the work can be simplified, understanding the relationships with other parts of the business, etc.

Departments are free to do deals with each other

With this approach, departments will figure out how to do deals with each other. They might swap sprints, because the scheduling better suits each other. They might agree to share sprints, especially if one department needs more design work done, while the other really needs build.

Or sometimes, something goes wrong and a feature doesn’t get finished within the planned sprint. In this case, a department lead might make a deal with the following department to get more time to finish the feature.

This sort of cooperation makes this approach work much more smoothly – and is very straightforward compared to the arm wrestling matches.

Remember the bugs!

Bugs suck and they emerge at inconvenient times. My favoured approach for bugs is to leave space in every sprint to fix them. While big bug weeks can help clear a backlog, realistically, it is difficult to ignore bugs altogether in the meantime.

Every department has to understand that if something major blows up in another part of the business, it has to get fixed even if it’s their sprint. Having some ground rules on what is an urgent, important bug and a clear idea of who is the final judge will save a lot of internal arguments.

How you know you’re doing it right: minimal internal lobbying

If you frequently find yourself in a meeting with lots of people playing a zero-sum game against each other, you can be pretty certain something is broken in your approach to making development decisions. When you have it right, the energy put into zero-sum games will go into solving real customer issues.

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.