I’m back

It’s been a while since I’ve last posted here. A lot has been happening. My wife and I started a family. My partners and I sold our company, so I now run technology across different businesses for the acquirer. My responsibilities have grown.

Outside my personal sphere, AI is rapidly changing the world. I’m typically the most skeptical person when it comes to tech fads. But this is for real.

A lot of has been on my mind. And so this post is a soft “restart” for this blog. A resumption after a hiatus. More to come.

GS Dun designs-and-builds technology to solve hard problems. 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.

Communication

Communicating better: my favourite tips

The nerve wracking thing about doing a post on communication is that there’s always room for improvement. I learned this the hard way my freshman year in Professor Rosen’s seminar. I learned it again my first year at McKinsey.

We communicate all the time, so we think that means we’re good at it. But without conscious effort, we simply repeat the same mistakes. The starting point is to recognise that we can always write better, speak better, listen better.

Here are some tips that have helped me so far.

1. Remember that the listener pays

If every speaker were to pay listeners for their time, communication would be perfect. The cost would force us to think before we improv our way through a meeting.

Speaking for 10 minutes in a 6 person meeting burns a man-hour. Imagine what you could get done with an uninterrupted hour. You could solve what the damn meeting is about.

Therefore, mentally note the cost of your comms. Target your content and audience properly. And don’t add colleagues “just in case”.

2. Pick the right medium

In an office, there are 3 ways to talk with someone:

Email
Chat (Slack, Whatsapp, etc)
Live (phone, video or in-person)

As you step up from 1 through 3, the cost to the listener goes up. But so does the speed and richness of the interaction.

Consequently, here is when to use each medium.

Email: response needed today with minimal back-and-forth
Chat: response needed this hour with moderate back-and-forth
Live: response needed now. Or it’s too complex for chat (lots of back-and-forth). Or relationship building is needed.

Pick the wrong medium and you get frustration. The most common mistake? A lot of meetings and chat should be emails.

3. Say it in fewer words

More specifically:

Say your point upfront
Draft emails – and then edit it down
Prep for meetings
Waffle sparingly

Explanation:

State your request/conclusion/question at/near the start. Make your preamble 5 seconds, not 5 minutes. Detail can come later
Emails are perfect for honing your skills in deciding relevancy and structuring information
Jot your points before the meeting. Otherwise you’ll talk rubbish while trying to conjure something insightful
Waffle is telling stories, jokes, etc. It can be great for bonding. But don’t overdo it

4. Signpost

Signposting is telling your audience about transitions. This is especially important in verbal comms. “There are 3 things I want to ask about: A, B and C” or “We’ve been talking about A. Now let me ask about B?”

In written comms, it’s easier. You have headers, bullet points and page breaks to help you.

5. Propose a strawman

When putting out a problem, don’t leave it open-ended. Propose something. e.g. “To acquire more customers, how about if we double our spend on ads?” instead of “What should we do to acquire more customers?”. The open-ended version of that meeting is easily twice as long.

Good communicator –> good decision-maker

Clear concise communication isn’t just a matter of style or convenience. It shows clear thinking. Deciding what and how to say something is complex. You have to prioritise, structure, decide relevancy, adapt to the medium and audience, etc.

You have to do something similar when making decisions. Therefore, as a rule of thumb, good communicators make good decision-makers.

But the paradox is that you never truly become good at it. Because as I learned back in Rosen’s seminar, the moment when you think you’re doing it well is when you need to be doing it better. There’s always room for improvement.

GS Dun designs-and-builds technology to solve hard problems. 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.

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.

A product design reading list

Like most skills, product design skills come from doing it (over and over). But a bit of reading helps. Here are books that helped to prime the pump.

Definitely recommended

The Design of Everyday Things by Don Norman

You would not think that a book featuring a teapot on the cover would be relevant to today’s digital products, but it is. Good design and bad design is all around us. You just have to look for it. And once you do, you’ll never look at doors in the same way again.

Rocket Surgery Made Easy: the Do-It-Yourself Guide to Finding and Fixing Usability Problems by Steve Krug

Krug’s most famous book is Don’t Make Me Think. Originally published in 2000, it made the case for the importance of design to the Web.

However, if you’re already a believer, I’d argue that Rocket Surgery is the one to read. It provides much more actionable steps for improving usability. But most importantly, it teaches you that improving usability doesn’t require a costly pseudo-scientific study of 100 target users. Just a handful of people will get you most of the way there.

The Non-Designer’s Design Book by Robin Williams

If you’ve ever tried to do a bit of visual design (e.g. for an interface) and it comes out looking woefully amateurish, here’s the book for you. It teaches you four key principles (with a handy acronym of CRAP): contrast, repetition, alignment, proximity. In other words, use CRAP to fix your crap. Ha (I’m too easily amused).

Theory of Fun for Game Design by Raph Koster

Despite the title, it’s not just for game design. If you’ve ever had to build something “engaging”, this will help you understand what it really takes. Basically sustained engagement needs tight feedback and a sense of progression, which has to be carefully balanced. Too flat = boring. Too steep = confusion. Key takeaway: it’s hard, takes a lot of investment, and the next time someone suggests simply gamifying something, just vomit on them.

Searching for something better

Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design by Michael J. Hernandez

Product design is often thought of as being a front-end discipline. But digital products are rooted in data. Hence you need to pay attention to the database: the information being captured and the relationships. It determines what your product can and can’t do.

Hernandez’s tome to teaching database design gets too nitty gritty for product design purposes. There are some gems in there, but you have to wade through several hundred pages.

For any aspiring database design book writers out there, I’d like to see something that teaches the fundamentals to a non-expert audience in less than 100 pages. Perhaps it should focus on “most common database screw-ups of startup teams”. Get it wrong and you can kneecap your product’s future flexibility and growth.

The book just primes the pump

Like in any discipline, it’s easy to take the literature and make it the end goal. Don’t get hung up on keeping things academically pure. The overwhelming key to moving forward is to just do it. Design, build, evaluate, iterate.

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.

Culture Strategy

The Cultural Web is the menu for your strategy breakfast

There’s a famous saying about culture eating strategy for breakfast. While the provenance of the saying is up for debate, I have no doubt about its accuracy.

The surprising thing (for me personally) is how much I agree with it. I started off my career doing strategy. A long time ago, I believed insight and structured decision making was all that a company needed to kick ass. But I didn’t appreciate how important culture is – nor its power to override even the most well-thought out strategy. When you see enough recommendations get accepted but not well executed, you start to understand that something else is at play.

Look at the leadership

The difficulty of culture is how to manage it? It’s air: pervasive and invisible. How do you get a handle on it?

While management frameworks are a dime-a-dozen, some stand the test of time. For culture, my favourite is the Cultural Web. It’s essentially a list of things to get you started when thinking about culture. In a nutshell:

Stories: what do people talk about?
Rituals and routines: daily behaviours and actions
Symbols: dress codes, office plushness, etc.
Organisational structure: formal and informal
Control systems: financial systems, quality systems, reward systems
Power structures: people who are truly powerful

The nuance I would add to this is that leaders have a disproportionate impact on culture. Coming in cold into a new organisation? Take a look at the CEO. In a small org, the CEO influence is huge in every corner of the company. In a larger org, then also look at department heads and other managers to understand the culture in one corner vs another. The CEO influence is still there, but it will be dissipated by that of the local office manager, department head, etc.

In other words, as a more focused use of the Cultural Web, I would start by looking at the stories leaders tell (or are told about them), their rituals and routines and symbols. It’s a bit anthropological, but it starts to point to what is realistic or not with regards to executing a strategy.

Can you change culture without swapping out people?

What if you want to change culture? What if you look at an org and you say, “this is no longer right for us”?

The classic Cultural Web framework would say that you do an audit and gap analysis. “Where are you now? Where do you want to get to? What needs to change?” Simple? Bullshit.

Culture is so intimately tied into individuals in leadership positions that you can’t change it wholesale. You can nudge it, mature it, evolve it. But you can’t take it back to the store for an exchange. Anyone who has ever made the fallacy of wishing someone would change (e.g. a family member or a friend) knows that adults don’t really just become new people. So if you look at your culture and realise that it’s getting in the way of where you need to be as an org, I really believe that you have to change the people.

That’s a painful conclusion. But I’ve never seen a culture change otherwise.

The less painful (and perhaps more realistic) route here is to adapt the strategy to fit the culture. There are many ways to skin a cat. Or in other words, any given team will have strengths and weaknesses. They’ll be able to execute some strategies but not others.

An honest appraisal of what they can and can’t do during the formulation of the strategy should be the first move. Play the strengths of what you’ve got already. And if it’s clear that isn’t enough, then make the swap.

GS Dun provides leadership for new ventures. 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

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.

leadership organization teams

Setting up a team of teams

For a growing organisation, one of the biggest questions is how to transition from being a single team to a team-of-teams. An organisation of 5 people is one thing. An org of 20, 100 or even 1000 is another. It requires some deliberate design.

But how do you make that transition? It’s intimidating. Every situation is unique. Your culture, sector, incentives, resource availability, financial position, etc all prevent you from blindly copying other organisations.

There isn’t a standard playbook. But here are some principles to follow.

1. Organise around purpose rather than function

A rapidly growing team will often split into a team-of-teams along functional lines. For example, your team might have a general manager, a couple of developers, an operations person and a marketer. Fast forward to a couple of successful years later. Your “team” is now 100 people. It wouldn’t be surprising to see the marketer running a marketing department of 15 people. Or one of the early developers in charge of a tech department of 20 engineers.

The problem with organising along functional lines is that the company’s big goals are typically multi-functional. Therefore a functional approach inherently requires managers to constantly negotiate with each other for resource and talent. It’s a crippling source of friction.

Instead, you should set out to organise around purpose. If you’re responsible for three different products, then put together cross-functional teams focused on those products.

Keep in mind that this isn’t a hard-and-fast rule. It’s a guiding principle. There will be times, especially when you’re in this awkward phase when you’re bigger than just a team (but smaller than full fledged team-of-teams) where it makes sense to be sort of functionally organised. Don’t break the back of the org to fit this rule.

One nuance to this principle is that a team’s purpose could be to provide a function internally. These are “internal agencies”, which could occur when cross-functional teams only occasionally require a specialised skill (which in aggregate across the company justify an internal team). A common example is legal.

2. Resource each team to follow the 80% rule

Previous posts explain a version of the 80% rule, which states that a team should contain the resources it needs to do 80% of its work (without outside resourcing). Basically this is an extension of the principle of organising around purpose. If you give a team a purpose, then give them the resources.

The subtlety here is that it might be too expensive. A business unit that consistently generates only 100k revenue year after year can’t justify a five person team. The temptation would be to stick just two people on it and say “borrow the rest from others”. This is a cop out. The team is setup for failure.

If it’s too expensive to follow the 80% rule, then increase the scope of purpose rather than setup a crippled team.

3. Hiring should involve multiple teams

Every hire made by a team should involve people from outside that team. Why? First, because teams interact with each other often and you want that interaction to be frictionless. Second, people will move teams over their careers. You’ll want that movement to be welcome rather than disruptive.

In terms of the extra-team checks done on a potential hire, it should be done from a perspective of “would I want this person on my team?”, both from a cultural fit perspective and a skills perspective.

4. Keep clean interfaces between teams

Even with the 80% rule, teams still have to work together a lot. When they do, messy interfaces between them can turn things into a total sh**show.

What do I mean by “interface”? It’s the rules and expectations for how the teams interact. In other words, it’s:

Who does what
How do they make requests of each other
How do they communicate
Obligations of each side
Turnaround time
Workflow
Etc.

For example, let’s say your company has an in-house legal team (their purpose is to provide timely legal advice). And let’s say they have to sign off on every marketing campaign that a team puts out. When should those requests be sent? How? Via email or an internal ticketing system? How fast should they be responded to? What detail needs to be submitted? Etc.

This won’t all be written in a rulebook. Most of it will be understood rather than documented, based on common culture, good relationships and prior experience working together. And it will evolve. But keeping it clean, you’ll avoid a lot of headache for your teams.

5. Strongly encourage cross-team relationships

Social events, shared kitchens and other spaces, functional networks, cross-team mentorship, office sports teams, etc all have a role to play. And that role is to build trust and awareness between individuals where it wouldn’t happen otherwise. Silos are a real problem of splitting into multiple teams and a variety of cross-team relationship builders go a long way to minimising that risk.

Beyond these principles, there are many other idiosyncratic considerations one should make when transitioning from a single team into a team-of-teams. But this is a good starting point for thinking about 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.