On Medium’s new ‘applause’ feature

I really like Medium’s new ‘applause’ feature for ‘liking’ articles.


The idea is that the extent to which you like something is not binary… it’s not either “I like it” or “I don’t”. It’s a spectrum.

There are other ways they could have done it. They could have made it a star rating, a rating from 1-5, or 0-10 (like NPS). But all of these have a meaning that’s so closely associated with rating things (hotel rooms, websites, products and so on) that it would feel odd attaching it to Medium content, where the author is clearly visible. Replacing it with ‘clapping’ makes it a much more human interaction.

Clapping is something we humans do all the time to indicate how when we like something, and generally, how much we like it. The more we like something, the harder and louder we clap. The Applause-o-meter is a common method for gauging audience reaction to a contest between a few different people, with the candidate who receives the loudest applause winning the match.

That’s what I like about the clapping UI on Medium. It takes a very common behaviour on the internet (rating something) and gives it a very human and emotional touch. The more you like a piece on medium, the more you click to ‘clap’ for it. This also makes clapping a lot more meaningful than just going for the 5 star button… each click to clap is an additional investment – you need to decide once again on each click if it’s worth one more – so five ‘claps’ is worth much more than one-click to leave a 5-star review.

The downside?
Each click is an additional investment. In our time-drained world, each click is a little bit of friction. Will people leave as many ‘claps’ as they might want?

There’s also possibility for abuse, such as clicking a hundred times on one article to artificially bump up the total number of claps – but that’s something Medium can easily secure against with a bit of logic.

Product Transparency, and some tips to help increase it

A little while ago I ran a retrospective with a product team where we focussed specifically on the product process. We invited a cross-section of the company: engineering, design, marketing, operations and the founders. Everyone present in the retrospective had the opportunity to give feedback on what was working and what wasn’t with regards to the way product management and product development overall was running in the company.

Sifting through the feedback, there was a common theme that encompassed nearly all feedback received: it all came down to transparency.

Everybody wanted more visibility into:

  • What the product team is doing
  • What they are not doing
  • Why they are/are not doing thing X
  • How the decision on what to do gets made and who is involved

Nearly all the different feedback points came back to one of these things.

It’s all about product transparency.

A more transparent product organisation leads to more trust and better-informed product decisions. It’s hard to imagine having too much product transparency. Some companies even publish their roadmaps publicly online for all to see.

Product prioritisation and planning should be an open book. There cannot be secrets in the product team. Any good product manager should feel comfortable articulating their rationale for any product decision whenever necessary. This is not about justifying themselves or proving anything – it’s about explaining the rationale so that everyone can understand why we do what we do. Often if the PM is uncomfortable explaining the rationale, it’s because there isn’t one – so the way to fix this problem is to ensure that product managers have a structured, goal-based and data-driven approach to product decision making.

People also want to feel like they are involved in the process. In my experience, people are happy to allow someone else to make a decision as long as they feel like they have been consulted and their opinion has been heard. Generally, people hate making decisions. It’s easier to find reasons not to decide at all – and if people aren’t involved in the decision process, that’s often exactly what they’ll do. But if they feel like they’ve been listened to, people are generally more than happy to let someone else take the responsibility for making the actual call.

Here are some tips for Product Managers who want to help make their product process more transparent:

  • Share the quarterly product goals/KPIs/OKRs regularly. Everybody should be able to easily quote what the product team is focussing on at any given point of time.
  • The Product Roadmap should be a public document that’s available for everyone to see. Keep it up-to-date and make it available on the intranet or somewhere that everybody has easy access to. Each item on the roadmap should clearly map back to one of the product goals (see point above).
  • For new features, run workshops to collect feedback and ideas from different people across the company.
  • Create an “idea box” that anyone in the company can use to submit product ideas/suggestions. Screen these suggestions often and interact with the contributors, so they know that someone is reading their suggestions. It should be understood by the team however that not every product suggestion will align with the product goals, so not every suggestion will be turned into a product feature.
  • Identify the stakeholders in the company for any key decision, and always try to collect direct feedback from them before making a decision. Even when – or especially when – your decision does not align with the stakeholders’ preferred outcome, the fact that you’ve consulted them beforehand will greatly reduce the likelihood that they will try to sandbag your progress after you make your decision.
  • Open your sprint/development planning meetings for anyone who is interested in attending. You should explain to any visitors that in order to keep the meeting efficient, they should avoid interrupting or asking questions – but the process of planning should be open and transparent for everybody.
  • Document the results of planning or design meetings, including the rationale for any decisions made, and post it somewhere shared such as the company wiki.
  • Share your learnings from all product workstreams as early, as often and as widely as you can. Whether it’s the results of an A/B test, findings from a customer survey or discoveries from customer interviews – document everything you learn and share it with the company. This helps bridge organisational boundaries and helps everyone align around a shared understanding of the customer. Plus the act of documenting and sharing information helps you as a PM understand and internalise the learnings as well – so it’s a double-benefit!

If you have some other ideas on how to increase transparency, I’d love to hear them! Either leave a comment below or send me a mail.

How to prioritise your time and stay sane as a Product Manager

I recently finished training a new Product Manager and on-boarding him onto a project. After his first week alone on the job full-time, he came to me on a Friday afternoon with a frazzled look on his face and asked me: “How do you cope with the continual and immense demands for my time as a PM – and then on top of that still find time to think about strategy, talking to customers, and evangelisation?”

This is the science, and art, of prioritisation.

I could point him to a ton of resources about how to approach product backlog prioritisation, such as the ICE method. But what he really needed to hear is not how to prioritise a backlog (although this is also important). He wanted to know how to prioritise his time.

I came up with these principles:

  1. Ruthless prioritisation of everything. You have to sort the world into “things that are important and urgent right now” and “things that are not”. And then to make this work, you have to ignore the things in the “not important” column! This is where many people get tripped up: they prioritise well enough but then end up working on stuff from the ‘not important’ area because an executive wants it, or because an important customer is asking for it…
  2. But in order to prioritise, you need to have clear product goals. This sounds like “duh” but you’d be surprised how many product teams I’ve seen who have no idea what the goal for the quarter is. They have a roadmap, sure… but what is the measure of the success of that roadmap? What ONE result/metric are you trying to move in this period (month/quarter/year)? A test of a good goal is that a) everybody can remember it immediately, and b) you can use it to make individual prioritisation decisions at any level (feature level, roadmap level, strategy level, etc). If for any item on your backlog/roadmap, you can clearly say that it either contributes directly to that goal, or it does not: then it’s a good goal. If you cannot, it means that goal – or at least, that articulation of it – is not useful for prioritising your strategy, which means it’s not useful as a goal.
  3. Related: Stack rank everything. For any two items, you must always be able to say which is more important than the other. Try the experiment: pick any two items from your roadmap, backlog, or wherever. Then ask yourself: if you could only have one of these things, which would it be? Do you have an answer? Good! If you don’t, then you need to get better at stack ranking.
  4. And finally: get used to disappointing people. It’s natural for Product Managers to measure their success against how happy they make their customers – both internal customers (colleagues, executives, engineers, designers, etc) and actual customers. But you’ll never be able to please everybody. We all agreed years ago that “design by committee” is a bad idea: try to build something for everyone, and you’ll end up building something for no-one. And yet, how many low-value items have you ever snuck into the roadmap because Sarah really wants it for her campaign, and she asked so nicely… Resist that urge. Learn to say (politely) no to requests, ideas and requirements that don’t align with what you’re trying to achieve right now. By all means, collect ideas often and from as many sources as you can: this can be a great source of inspiration and creativity for you. But don’t create expectations that every idea is created equal (because they aren’t).

This is how to stay productive – and stay sane – as a Product Manager.

Good luck!

Three Core Characteristics of Great Product Teams

There are many characteristics of great product teams. But when I think about what the very best teams have in common, there are a few common core elements that I think tend to lead naturally to many other great attributes. Characteristics like high levels of trust and motivation, proactive attitude, open communication and knowledge sharing – these all spring from having solved three core team competencies.


Read on to see the details of each criteria and rate your team on a scale of 0-5 for each. How great is your product team?


Shared understanding of the customer

Great product teams understand that great products come from a deep understanding of the customer: their needs, their problems, their desires. All other things being equal, the company that understands the customer best will win the market.

It’s crucial that the customer is at the core of every decision, and that everybody has the same shared view of who the customer is, and how you deliver value to them.

Level What you should expect at this level
0 Who is our customer again?
  • Your Product Manager receives product ‘requirements’ from the founders/business/marketing/sales team, and consolidates these inputs directly into a backlog.
  • The priority or target users for these features are not discussed among the team.
  • Your Product Manager uses the customer segments provided by the marketing team to build the product strategy.
  • the PM makes priority and strategy decisions alone, or with the founders/business team directly.
  • the engineering and design team execute work from the backlog.
  • Your Product Manager spent some time at the start of the project out of the building talking to some customers to validate the segments provided by marketing, but hasn’t really spoken to many (or any) customers since.
  • Your design team perform usability tests from time to time, but the results are not widely shared outside of the design team.
  • the Product Manager has some rough personas, but these are not documented. The design team also has some personas they use, but these are different from those used by the PM. Engineering don’t have any personas at all.
  • Customer research results and analysis is rarely shared between groups.
  • Your Product Manager and designers can succinctly answer the question “Who is your customer?”
  • Your Product Manager is in regular contact with existing users as well as non-users from your target market.
  • Your Product Manager and Designers regularly use aligned customer personas when making product decisions.
  • Your designers perform regular usability tests.
  • Results and analysis of user research is presented to the team at regular intervals in knowledge-sharing presentations.
  • Your team shares a complete understanding of the customer. Any member of the team – from PM, to QA, to engineering – can succinctly answer the question “Who is your customer?”
  • Your Product Manager is in regular contact with existing users as well as non-users from your target market.
  • Usability testing is a regular and recurring part of your product development lifecycle.
  • All members of your team regularly take part in usability studies.
  • Results and analysis of user research are distributed and discussed widely in the team.
  • You have clear customer personas for your target segments and they are used by all members of the team when making all product decisions. All members of your team regularly say things like “What would [our key persona] Alex do in this situation?”



Great product teams understand that great products come from a deep understanding of the customer: their needs, their problems, their desires. All other things being equal, the company that understands the customer best will win the market.
It’s crucial that the customer is at the core of every decision, and that everybody has the same shared view of who the customer is, and how you deliver value to them.


Level What you should expect at this level
0 No product focus: it’s Product Anarchy.
  • There is no clear product roadmap or backlog. Tasks are thrown to the team ad-hoc.
  • Prioritisation is random, and is generally based on the HiPPO’s feature requests or who is screaming louder.
  • There is no clear KPI defined for any tasks.
  • Your team spends a lot of time doing low effort/low impact work.
  • Stopping work on something the team has started but not finished is extremely frequent. You have a massive pile of started-but-not-finished work.
  • The majority of the design work from the design team is never implemented into the product by the engineering team. You have a massive backlog of old designs that were never implemented.
  • The engineering team frequently starts work on things that haven’t been fully specified or designed yet because they are suddenly ‘urgent’.
  • The team appears to be constantly putting out fires.
  • There is a product backlog, but it changes every week. There is no roadmap beyond the next 1-2 months.
  • Prioritisation appears random, and is generally based on the HiPPO’s feature requests or who is screaming louder.
  • There is no clear KPI defined for any tasks.
  • Your team spends a lot of time doing low effort/low impact work.
  • Stopping work on something the team has started but not finished is frequent.
  • A lot of the design work from the design team is never implemented into the product by the engineering team.
  • The engineering team occasionally starts work on things that haven’t been fully specified or designed yet because they are ‘urgent’.
  • There is a clear, prioritised product backlog. There is a clear product roadmap for the next 12 months. The roadmap goes through major change about once every 2-3 months.
  • Prioritisation is based on business needs, but HiPPO feature requests or emergencies frequently get thrown in on top.
  • Major product epics/tasks have clear KPIs so you know exactly when you’ve achieved the stated goal.
  • The team only occasionally stops work on something they have started but not finished.
  • Small amounts of design work from the design team is never implemented into the product by the engineering team.
  • The engineering team rarely starts work on things that haven’t been fully specified or designed yet because they are ‘urgent’.
  • There is a clear, prioritised product backlog. There is a clear product roadmap for the next 12-24 months. The roadmap rarely goes through major change.
  • Prioritisation is based on business needs and product objectives/goals.
  • Most product epics/tasks have clear KPIs so you know exactly when you’ve achieved the stated goal.
  • The team rarely stops work on something they have started but not finished.
  • Generally all of the design and specification work from the Product and Design teams is implemented into the product by the engineering team.
  • The roadmap and product backlog are clearly prioritised against business and product objectives/goals.
  • Changes to the backlog or roadmap are accompanied by a clear rationale that is linked to external forces or changing business needs.
  • Prioritisation is based on leverage to impact the stated goal, versus effort.
  • All product epics/tasks have clear KPIs so you know exactly when you’ve achieved the stated goal. You probably use OKRs or similar for articulating product objectives.
  • The bulk of your work is in the high effort/high impact area (generating core business value).
  • Your team avoids low effort/low impact work.
  • Stopping work on something the team has started but not finished is extremely rare, and only happens in conjunction with major external forces.
  • A great sense of urgency in the team is based on a shared desire to deliver value to the customer as quickly as possible. “Firefighting” emergencies are rare.


Product, Design and Engineering Teams are 
tightly integrated

Great products are a perfect synergy of an urgent and pervasive market problem, and a solution based on a delightful user experience, enabled by technology.

Product, design and technology.

So it should come as no surprise that the teams who deliver the best products integrate product, design and technology closely.

Level What you should expect at this level
0 PM Dictatorship: subversion will be punished!
  • The Product Manager works alone with the founders/business teams. Priorities and instructions are given as ‘marching orders’ to design and engineering teams.
  • The Product Manager presents complete specifications, including wireframes and UX specifications, to design. Design’s job is to ‘make them look good’.
  • Engineering receives finished designs, and told to ‘implement this’. Engineering teams implement blindly and do not question, even when the design is contradictory or doesn’t make sense. (“It’s not my fault – I followed the spec!”)
  • Design and Engineering teams feel little or no ownership of the product.
  • The Product Manager works predominantly alone with the founders/business teams on the product strategy and roadmap.
  • Design feel some ownership of the product, but their view of the product strategy and agenda is created separately from Product or Engineering.
  • Engineering are working on a technical framework roadmap, but doing so separately from Product or Design.
  • The Product Manager involves Design in the solution definition for most product initiatives/tasks.
  • Engineering are handed final specs for execution.
  • There is little knowledge sharing between disciplines.
  • Product Strategy, Design Strategy and Engineering Strategy continue to exist as separate entities, but they are discussed collectively and an effort is made to link them to one set of business objectives. Ownership of each strategy remains fully within the respective domain.
  • Design is involved in the problem definition phase for most product initiatives/tasks.
  • Engineering is involved to provide feedback on feasibility, but is not encouraged to comment on the problem definition or solution beyond effort and feasibility.
  • Information is starting to flow between disciplines, but the flow is controlled by the respective discipline leads.
  • Product Strategy, Design Strategy and Engineering Strategy are combined into one overarching Product Strategy. Ownership of the strategy is shared collectively among the Product Manager, Lead Designer and Lead Engineer.
  • Product, Design and Engineering are involved in the problem definition phase for most product initiatives/tasks.
  • Prioritisation and solutions are frequently discussed between the three domain leads. The PM occasionally pulls rank to veto a decision she/he doesn’t agree with.
  • Everybody in the team is encouraged to give feedback on the product, specifications and designs.
  • The Product, Design and Engineering teams work inseparably from each other.
  • The Product Manager, Lead Designer and Lead Engineer work closely together daily. They constantly share knowledge, learning and advice among each other.
  • All three disciplines are involved from the start of any project or product initiative. Product strategy, roadmap and prioritisation are performed collectively.
  • The Product Manager, Lead Designer and Lead Engineer each have deep understanding of their areas of competence, but are comfortable discussing and challenging other areas.
  • The Product Manager, Lead Designer and Lead Engineer work together for all major decisions, but also trust each other sufficiently that decisions can happen if someone isn’t available for a discussion. Nobody is a bottleneck.
  • Everybody in the team is encouraged to give feedback on the product, specifications and designs. Nothing is taboo.
  • Disagreements and debates are based on an objective discussion of user value and the personas.
  • The PM never pulls rank to veto a decision she doesn’t agree with.
  • Product, Design and Engineering teams feel shared and complete ownership of the product.



The characteristics of good teams mostly comes down to team culture: and culture is the product of the norms and ways of working that are established in the team.

You – Product Manager, Lead Designer, founder – have more influence over this than you probably think.

Think about how you can up-level your team in each of these three categories. If you get to a 5 for all three of these areas, I guarantee you’ll have a fantastic, high-performing team and a great product.

If you have any feedback on the model, I’d love to hear from you!

A simple framework to triage and prioritise new ideas

For any product startup, prioritisation is everything. Spend time working on the wrong things, and you’ll waste both time and money – two things you have in very limited supply as a startup.

Lots has been written about prioritisation in product teams, and it’s often cited as one of the biggest challenges facing startups and product teams today. But it’s really not that difficult if you approach it with deliberate focus.

At it’s core, prioritisation is simple:
Find the highest-leverage things (features, services, tools) and focus on those first.


As a Product Manager you’ll be constantly bombarded with new ideas: the might be your own ideas, they could come from the founders, from customers, from investors, or from your team. There’s never any shortage of ideas – and that’s great. The problem is that investigating and assessing these ideas takes a lot of time. To make sure you only spend time on the things that matter, (and to keep your sanity), you need to be able to quickly and effectively triage this flow of input.

I have a simple two-step framework I use to quickly triage ideas.

Does this idea, if implemented, directly and positively impact our key product goals/metrics?

This step is simple. You just need to ask: if we do this, will it have an impact on what is important?

(The prerequisite is, of course, that you already have a clear view on what your product goals actually are. If you don’t, then you need to get that clear right now – otherwise, how can you prioritise anything? With no key goals to prioritise against, how can one thing ever be more important than another?)

Will this idea, if implemented, have a positive impact on the goals you’re trying to achieve? Does it have leverage? If the answer is ‘no’, you know you can immediately stop investigating. Maybe this idea will be useful later, when your product strategy matures and focuses on other goals, or maybe it will never be useful. Either way, don’t waste any more time on it.

Note that in Step 1 we don’t consider how to implement the idea. How is irrelevant at this stage: the only question that matter is: is this the right thing to do?

Is the effort/impact tradeoff aligned?

Once you’ve weeded out the ideas that are not going to impact the product goals you care about, you can assess if the value/effort tradeoff is aligned. Map the idea on the Effort/Value grid:


If the idea doesn’t fall into the top part of the graph, discard it. You don’t want to focus on low-value items: even when the effort is really low. Avoid the trap of thinking “oh well, it’s only a couple of hours’ work, so…”. Every hour you spend on low-value work is an hour you’re not spending on high-value work. Don’t do it.

(You can read more about the effort/value grid here.)

If you’re honest with yourself about the value each idea contributes, and to which goal, you’ll find you can safely discard many, if not most, of the new ideas that come flowing your way. When you learn to filter and triage quickly and effectively, you’ll minimise the time you spend on dealing with noise and be able to spend more time focussing on what’s important.

Try it out and feel free to let me know how it works for you.

The value of talking to customers

I spent about 4 hours last week conducting usability tests. No matter how often I do this, it always amazes me how incredibly valuable it is. Every test reveals something new about the product.

As a coincidence just this week I also came across this article talking about how many Product Managers lament that they don’t have time for customer or market research at all.

“I am too busy writing specifications to be able to do the important customer feedback, research, and strategic work.”

I see this all the time in product teams, and while I get it that there are always more specs to write and more bugs to triage, I always say:

What could possibly be more important than knowing you’re building the right product?

All other things being equal, the company who understands their customer the best will win the customer, and the market.

Talk to your customers. If you don’t have customers yet, then find people in the market who match your target segment and talk to them.

For some tips on how to do that, check out this video.

But whatever you do: get out of the building and talk to your customers.

Great PMs don’t work alone

Sometimes there’s a perception of Product Managers that the best ones are product geniuses who always and immediately have the right answers for every product problem: PMs whose product instincts are so sharp they can arrive at the best solution at a moment’s glance; who can look within themselves and find the solution deep down there and pull it out onto a wireframe through a simple act of will.

I suppose there are a few crazy geniuses out there. And I’m certainly not doubting the power and value of instinct built up over years of product experience.

But the whole truth is that being a great Product Manager is less about moments of divine inspiration, and more about work and grind: questioning, discussing and iterating. Hypothesising, experimenting, failing and repeating. Doing the work.

The whole truth is that great PMs don’t work alone. They’re not mad geniuses who are supposed to always have all the answers.

Great PMs are masters of The Process: the process of gathering input and inspiration from myriad places, and synthesising that into a solution. PMs talk to the customers, to the sales team, the finance team, the engineers: they talk to everybody. They know that ideas and inspiration can come from anywhere, and they actively seek out ideas and input from across the business.

But be careful. This is not the same as “gathering requirements” or “translating business objectives into development objectives” (two definitions that often come up in the context of Product Management that I really hate).

This is not about making sure everybody’s input and ideas are squeezed in to the product. It’s about a process of gathering ideas and inspiration from as far and wide as possible (the divergent thinking phase), then boiling that all down into the solution that best solves the problem for the customer (the convergent thinking phase).

Product instinct is less about always knowing what the solution is. It’s much more about knowing which solution, from a list of possible ones, is most likely to work, and which should be tested. It’s about quickly assessing and prioritising a variety of options and making the right call.

So don’t think you always need to have all the answers. Use your team and your network to build your list of options, pick the best one, or combination of best ones, and go.

On copying well: apply with caution

The Exponent podcast this week on the history of messaging apps talked a lot about copying. They referenced a previous piece from Ben called “The Audacity of Copying Well”, where he talked about Snapchat stories, and how this was so obviously and shamelessly copied by Instagram to make Instagram Stories.

They argued that in business, copying what works from the competition is not only inevitable, but it’s what businesses do to survive and thrive.

If your business is based on something that is easily copyable, then you don’t have long-term competitive advantage. Someone will copy you, do it better and then you’ll be dead. Period.

Every basic business strategy class will teach this. So why do we have this moral outrage when it comes to copying in tech?

There should be no moral objection here. All new tech businesses are essentially taking a known product or theme and building on it; expanding it. On the podcast, James argues that the fact that we have so many companies building off each other’s ideas is precisely the reason there is so much innovation in tech right now.

I wrote yesterday about the danger of copying when you don’t know if it’s working. I was thinking more about copying UX patterns or conversion tactics – but the same is really applicable to business models as well. Learn from your competitors. If they have built something that is easy to copy, and that thing can help your product/business succeed, then use it.

But the warning here applies to copying business models as well. By all means learn from business models that are working elsewhere: but apply with caution to your own business and your own market.

Copy with caution.

The danger of copying

It’s normal when building and optimising a product to take a look at how others have solved similar problems in the past. In fact, this is a critical part of the design and product research phase.

But be careful with assumptions like “Company XYZ does it this way, and they know their shit: they wouldn’t do it that way if it didn’t work, so we should do it that way too.”

I’ve heard PMs and designers say things like this all the time, and although it’s tempting to believe when you’re under time pressure to ship, it’s rarely the right decision just to blindly copy the competition or whatever reference model you’re looking at.

The thing is: from the outside looking in, you have no idea why they decided to solve the problem in the way they did. You don’t know the context of their users and their business.

And you don’t have the data. You don’t know if it’s even working.

Maybe that solution isn’t performing at all and the product team hates it, but they haven’t had the resources or time to improve it yet. You just don’t know.

Get inspiration from those who have solved similar problems before you. The product world is full of incredible people that ship innovative solutions every day, and it would be foolish not to learn from that. And yes, there’s no point re-inventing the wheel. But remember that not every wheel fits every vehicle. Implementation and context is everything.

So don’t copy blind. Don’t assume it will work for you directly. Learn from the best; then make your own decision. Then instrument with good analytics, measure and iterate.

Good Speed: 6 ways to build product faster

Product Management Speed

I recently wrote about why Speed is not the same as Velocity.

Speed is just moving fast, whereas velocity is moving fast in the right direction.

Fred Wilson also posted this week on Urgency, and how in his role as a board member and advisor he presses startups to foster a healthy Sense of Urgency in the business. A healthy sense of urgency breeds what I call Good Speed.

Good speed has a positive impact on your velocity and brings you closer to your goals. Bad speed takes you further away from them.

So what is good speed, and how do you create it?

Here are some PM Rules of Good Speed.

1. Prioritisation

Good speed is about good prioritisation.
Prioritisation is all about answering the question: what is the most valuable thing we can do next? What is the next highest leverage option?

In my previous Growth Team I used the I-C-E method (Impact, Confidence, Effort) for helping to quickly prioritise roadmap items:

  1. Impact: how much value we can deliver to the customer?
  2. Confidence: how certain are we that it will deliver the value we expect?
  3. Effort: how much effort will it take to deliver, and what are the opportunity costs (what are we unable to work on in the meantime)?

Always deliver the highest value things first.

2. Focus, focus, focus

As a PM you’re always in a situation where you have multiple ongoing initiatives: open customer requests and bugs, that strategic partnership, the platform refactoring project and other technical debt, not to mention your product backlog of new features and improvements. It can be tempting to work on many different things at once, as it gives the feeling of progress and momentum on everything. Unfortunately, this is usually a false economy. The more plates you have spinning at once, the more often the team will be context switching between topics, and each thing you’re doing will end up taking longer.

Great prioritisation is all about the things you don’t do.

3. Finishing, not starting

There are always new requirements coming in from all sides. You’ll often feel pressure from stakeholders or customers to stop working on what you’re doing to “squeeze in this important requirement” or “respond to this change”. But if you’re halfway through something, it’s a good idea to finish it first before moving on to the next thing. Putting a task down, and then picking it up a couple of weeks or months later is a big waste of time. You’ll all spend time getting your heads back into the topic, finding the specs and designs, figuring out where you left it, which branch it’s on, etc. The half-written code will be stale, will need to be re-based or maybe even re-written. In the worst case you’ll have to throw away everything you worked on and start from scratch.

Resist the urge to change priorities mid-way through delivering value, as it makes everything more expensive in the long run. Even if it feels like the right tradeoff in that one moment, do the exercise of adding up all the times you do that over a year, and the impact that all those times added up will have on the total value delivered…

3a. Reversal: Beware the sunk costs fallacy

The reversal to this rule applies when you learn something that renders what you are working on right now obsolete. Maybe the company strategy changed, or you obtained new market data. Whatever the cause, if you learn the thing you’re working on is of low value, pull the plug early. It can be tempting to think “… but we’re already half done, we might as well finish it…”. Don’t. The time you’ve already spent is already spent. It’s sunk cost – you can’t get it back. So if the time you spend finishing it could be spent on delivering value that will positively impact your business – then absolutely do that instead.

4. Time to value

Time to value is about how you structure your roadmap and break down features to get to the core value as quickly as possible.

Focus on what is needed to deliver the core value to the customer, and on building that. If what you’re doing is peripheral to the core customer value, consider doing it later, or not at all.

5. Tradeoffs

Fast is often also about making tradeoffs.
The classic: “Let’s skimp a bit on quality now to get the feature out the door, and we’ll fix the bugs later.” Every product team has limited runway ahead of them, but the life-or-death feeling is particularly acute in a tech startup. The pressure from the market to get to value as quickly as possible is real. But make no mistake: skimping on quality is taking on debt. You’ll need to pay it back eventually. Understand this; and make the decision to take on debt consciously, and as a team.

Related: this fantastic article on classic over-engineering mistakes software teams make.

6. Motivation and energy

A high level of motivation and energy will make the difference when it comes to that last 2% that takes you over the finish line. It makes all the difference between “I have to get this done before I go home tonight” and “I’ll take care of that tomorrow.”.

Remember: you cannot mandate motivation, but you can provide the mission and the environment that breeds it.

Good speed is a positive Sense of Urgency.
Get focussed and get finished.

1 2 3 4 5 18