Posted on

Achieving Extraordinary Results with Ordinary People – Marty Cagan

Notes from a talk by Marty Cagan, at a Product People meetup hosted at Geovation on 19 October. Marty Cagan is from Silicon Valley Product Group has worked at places like Netscape and eBay back in the day, and advises lots of startups on how to do tech product management.

Empowered teams

Bad approach:
Tech teams exist to serve ‘the business’.

Good approach (product culture):
We set up teams to serve actual customers, meeting their needs in a way that they love, but in a way that meets the need of the business.

Why don’t most organisations do this?

Trust. Senior management don’t think that they can trust subordinates with decisions. They think the people aren’t capable.

Coach Bill Campbell, who coached Amazon, Apple and Google founders:
“Leadership is about recognising that there’s a greatness in everyone, and your job is to create an environment where that greatness can emerge”

The role of leadership

Leadership is about inspiring people to a goal. Leaders need to provide:

  • Product vision – a north star aligning every discrete product team in the organisation. Needs to be inspirational. It’s the main recruiting tool.
  • Product strategy – the plan for getting from the current state to the desired end state. Not a product roadmap – more a sequence of big milestones.
  • Product principles – princples to help you make difficult product decisions. e.g. at eBay resolving the fact that the seller team had a lot of power, and that could lead to buyers being treated worse. So eBay established a principle of always favouring the buyers, because if you take care of the buyers then the sellers will come.
  • Product priorities
  • Product evangelism. “If you ease up on evangelism there’s always someone that is going to take your resources”

The role of (people) management

“It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.” – Steve Jobs was negative, but he didn’t tell people how to fix things. He gave them space to do that.

  • Staffing. Put the right people in place and don’t set them up to fail.
  • Coaching.
  • Objectives (Not roadmaps. Give people business problems to solve. Let the team figure out how to solve the problem. Make sure that different teams’ objectives are reconciled with each other. )

The Basis for Trust

You need to get the right competencies in the team.

Trust needs competence and character.

Often managers don’t know or understand the needed competencies.

The All Blacks have a “No Dickheads” rule. They’ve kicked players and coaches over this principle of character.

“Cultural fit” is a bad thing to recruit for because it leads to hiring people like the people you already have.

The best way to recruit is to go for competence and screen out the jerks.

How to tell if a team is empowered

  • The team is staffed with competent people with character, covering the necessary range of skills. (e.g. having teams with engineers and product and design)
  • The team is assigned problems to solve, and they are able to decide the best way to solve those problems. (Not implementing features on a feature roadmap. 3/4 of those features won’t solve the problem. Do whatever features you need to do to solve the problem.)
  • The team is accountable for solving the customer or business problem (i.e. delivering an outcome). Leadership gives the objectives – e.g. make the churn rate better. The team gives the key results – e.g. saying that we think we can do a 10% improvement. Teams can suggest objectives, but the organisation needs to think about coordinating and prioritisation organisation-level objectives, so needs to drive this process.

Bonus: Cagan’s thoughts discovery

3 things you need in a good team:

  1. Are they tackling the big risks up front? (value, usability, feasibility, business viability) PM responsible for making sure that we resolve these risks (or at least well enough) before we write production code.
  2. Are they collaborating closely around the problem, rather than passing it around between disciplines?
  3. Not about implementing features, it’s about getting results. shipping things on time and budget is not important – it’s about getting results. time to money is more important than time to market.
Posted on

Digital Product Managers should be able to code

Aspiring Digital Product Managers often ask me if they need to know programming to do their job. I always used to say ‘no’, but now I’ve changed my mind.

As a Digital Product Manager, you own the value and purpose of your team’s work. You are responsible for the vision and the ‘why’. Understanding ‘how’ is the job of your colleagues who are all focused on delivering the vision.

You are never going to be an expert in all the domains of practice in your multi-disciplinary team. You shouldn’t be. You’ve hired designers, user researchers, performance analysts, developers and data scientists to be experts in their craft, so give them space to own their specialism.

So a Digital Product Manager should never write code at work. But I think that you should be able to write some rudimentary code, having had a serious play around, because it will help you think better as a Product Manager.

As Product Manager you should have a sustained critical engagement with the core domains driving value for your product. And you should be interested in the frontiers of value in your team’s work. If you’re a Digital Product Manager that probably means learning about digital technology.

You don’t need a computer science degree or technical background – a humanities degree is a strong fit, given the need to understand what ‘value’ means in a number of different domains, and to synthesize, integrate and communicate this understanding. What matters is curiosity, excitement, optimism and a lot of dour pragmatism.

When working with a user researcher, you don’t tell them how to do their job. But you know the types of question to ask, and how to interrogate and work with the answers. You need to be able to do the same thing with technology – you can’t just leave it as a magic black box. You need to be able to critically engage with software engineering to at least the same level of competence as the other specialisms in your team, and probably more, given its central role in defining what is possible. What’s special is that your engagement is focused on value rather than delivery.

Explore, ask questions, and continually think about how this domain might relate to the problems that your product is trying to solve.

Some practical next steps: If you want to be a Product Manager, learn what a function is, have an appreciation of boolean logic and ‘if’ statements, get your hands dirty writing some poorly laid-out code and deal with the consequences, play with an API or two to see the kind of value they provide, store some material in a database, play around with something that you find fun and interesting. I’ve written some guidance on learning programming here. There might be other specialisms in your team where your knowledge falls a bit short – such as data science. Take the same approach there.

Posted on

What is [email protected]?

Yesterday’s Digital Project Managers London meetup looked at the Scrum @ Scale framework.

The event was mostly questions and answers, so what follows is a blend of that material, bolstered with content from the Scrum @ Scale website.

The goal of Scrum @ Scale is to allow organisations to scale effectively, rather than finding diminishing returns as growth leads to complexity and confusion. So it’s solving a higher level problem than the Scrum framework, which is focused on individual teams.

The Scrum @ Scale framework is deliberately minimalist. It’s a “minimum viable bureaucracy”. So you can build what you need on top of it to fit your culture or existing practices.

The key point is that you have scaled daily scrums going up the organisational hierarchy.  Issues that can’t be resolved at one level are taken up a level.

You have scrums, scrums of scrums and (if you need it) scrums of scrums of scrums. The scrums above the normal scrum are delivery focused – so made up of Scrum Masters or Delivery Managers. Focused on the ‘How’.

The highest scrum is at executive level. This Executive Action Team has the political and financial power to unblock impediments. So if a team needs a policy change it can get senior attention on it that same day. (Of course, that senior level chooses what it wants to do with that escalated issue.)

This Executive Action Team has a transparent backlog and ideally daily standups. It’s responsible for the transformation backlog and for the quality implementation of Scrum in the organisation.

 

 

There’s an equivalent Product Owner / Product Manager framework, focused on the ‘What’ and the ‘Why’.  It includes key stakeholders, not just Product people. On a sprint by sprint basis you have coordination of backlog prioritization at each of these levels.

The MetaScrum exists to:

  • Create and express an overarching product vision.
  • Build buy-in to the prioritised backlog.
  • Measure value and metrics
  • Create a shared definition of done that applies across scrums of scrums.

The Chief Product Officer sets strategy and vision for the product.

MetaScrums can scale up like Scrums of Scrums can.

You get up to the executive meta scrum level. At this level, organizational vision and strategy is set, aligning all teams around common goals.

Posted on

One way of running an agile team

At the Government Digital Service (GDS), we divide our work up into 3-month missions. We’ll give a multi-disciplinary team of about 10 people a particular problem to solve or a high-level idea of a piece of value to deliver within 3 months. We vary scope as we go, with time and resources being fixed. We build our understanding as we go, and change our approach as necessary to deliver the most value in the timebox. We’ll generally plan work to increase our understanding of what the right thing to do.

As Product Manager, my role is to make sure that we’re solving the right problems, and that we’re getting the most value from the work we do.

At the start of a mission, I set some clear overall goals for that quarter. Be upfront about what you’re not working on, so that everyone’s clear.

Work back from the end state you want to get to at the end of the quarter – e.g. migrating from one supplier to another, or launching a new feature that successfully meets its goals – and think about the things that will need to happen to get there. This will generate some milestones. You can start to build a high-level plan of what’s coming up in the quarter by mapping when you think you can hit these milestones. Do this with your delivery manager and tech lead, so that it’s sensible. It’ll change as you go, and that’s fine. I like to do this with post-its on a wall in the team’s space.

Within this structure, I like to work in weekly sprints. This means that you plan the detail of your work a week ahead. I like to run sprints from mid-week to mid-week, so that everyone knows what they’re doing on Mondays and Fridays, and those days can be kept free of meetings.

I run planning with the whole team – which is really important to build a shared understanding of the problems everyone is working on, across the disciplines. A day or two before the planning session, I’ll have a series of conversations to decide on the most valuable work to be done in that sprint. Some of these will be with my tech lead and delivery manager, others will be with the different specialisms in the team (e.g. user research, performance analysis or content design). The goal is always to check in with the big picture aims for the quarter, dive into any thorny questions we need to think about, or work to review in detail together, and then agree on what do work on in the upcoming sprint. Often this will be something already mapped out at high level, and now we start to consider the detail, but sometimes it’ll be something new.

These pre-planning conversations are a lot of fun, and a chance to think deeply about each of the disciplines in my team. They align us on goals and scope for the week – so we’re thinking carefully about how much is responsible to try and take on. In most quarterly mission teams I’ve been on, we’ve found estimating doesn’t work too well, as there’s lots of uncertainty inherent in a mission, and with a newly-formed team it takes a while to understand your velocity. So we rely more on gut feel, experience and the ability to iterate week-on-week if we felt a given sprint had too much work or not enough.

Once these conversations have finished, I’ll leave the different team members to write up cards to describe the work. I have a standard format I want cards written to – they need to have a ‘What’ and a ‘Why’ that anyone in the team could understand. But I don’t need to write the cards myself – it’s good practice for people to be able to communicate about their work, and it saves me time. If someone is struggling with writing cards to this standard, I’ll take the time to pair with them to iron this out.

The goal of writing these cards is to inform a robust planning conversation. Going into the team’s weekly planning session, we want clear goals and alignment on the big picture from each of the specialisms. The goal of planning is to think through the complexity of the work as a team, to really flesh out the detail of the cards – adding acceptance criteria, or thinking about how we might tackle a thorny technical challenge. But it’s also to build a shared understanding of what the other disciplines are working on – in a time-efficient way.

Ideally I’ll introduce some goals for the sprint, covering each of the specialisms. Probably tied in to the milestones for the quarter, that get us to our goals.

Once I’ve introduced the overall goals, and we’ve nuanced them if we need to, then we go into talking through the individual cards. I usually invite other people to introduce their own cards, and then I make sure that there’s a good quality converstaion on each card – making sure that by the end of the discussion we understand the value we’re trying to deliver, and have thought about the approach we want to take.

So this session is about sense checking, challenging, thinking about approach – but isn’t proscriptive about approach. The person who decides to work on the card takes the lead on that, calling on others for support if needed. Planning is very useful for being proscriptive in defining quality, and in adding acceptance criteria to a card. As with planning overall, making sure we know what we need to do is more important than how – the how is worked out in the ground.

Posted on

Why it’s better to manage Products than Projects

The different between project and product manager might sound semantic, but is actually quite significant. This post gives an overview of the differences, and explains why I think product management is the better approach.

Project management

At a high-level in the organisation, an end goal is decided. It’s also determined what work should be done to achieve this goal. Often this type of thinking and decision-making happens in an organisational or directorate strategy.

Project management is focused on delivering the specified output.

A project will usually be a discrete chunk of work, with some concrete deliverables, tied to a fixed pot of funding.

Product management

At a high-level in the organisation, leadership identifies a set of problems to solve, or goals to achieve.

In contrast to the project management approach, this is where senior direction stops. The product team – in particular the product manager – now has to figure out how to solve the problem or meet the goal. The task of figuring out how to reach the goal is devolved, and the product manager takes responsibility for maximising value within constraints. They vary the scope of what they build, and iterate their product over time, starting small and constantly testing hypotheses to test against risky assumptions, and to increase the value of what they’re delivering.

This approach places responsibility for the success or failure of the work on the product manager. Rather than following someone else’s idea, the product manager has to lead the process of working out how to accomplish the goal. They need to deeply understand the value they’re trying to bring, and act as the intersection point between users, analytics, technology and the organisation.

Funding is more usually ongoing.  This is because if you have a big problem it probably won’t get solved once-and-for all through a short burst of work. Or if you want to grow something valuable, you’ll get better returns if you invest over time.

Why product management is better

  • Understanding is emergent. People closest to a problem have the richest understanding of how best to solve it. We usually don’t know in advance which tactics will work and which won’t. This means that an approach that empowers the team on the ground – who will have far closer understanding of the problems than any senior manager – is better. The product manager, holds a strong understanding of the purpose of the work and of the different domains in their team, and can make very rapidly make holistic management decisions in response to new information.
  • Work involving human beings is risky. There are lots of unknowns when building things that interact with humans. Releasing working software regularly, testing assumptions, measuring impact against goals, and iterating to achieve better impact, is better than just delivering something that seemed like a good idea to a senior manager when they were writing a strategy.
  • It empowers and energises the team. You let the team own the problem and the solution. Organisational leaders are freed up to set overall vision and goals – a high-value task that better uses senior managers’ broad strategic view than micromanaging teams who have closer situational understanding than they ever will. It’s healthy to give staff interesting problems to solve, and demands more of them.
  • Ongoing investment is better than boom-and-bust creation and ending of projects. Once a project finishes, people spend less time thinking about it. Knowledge and context is lost, and money and people are devoted to other things. This makes it more costly to improve this area in the future. It’s more efficient and effective to invest seriously in a problem or an area where value can be added, and build a product that gets better over time, along with a persistent organisational understanding that gets more robust over time, as iteration after iteration builds knowledge.

So if you’re a leader, give people problems not projects. If a problem is worth solving, or you want to create new value in an area of your work, make that an ongoing investment. Make the overall purpose clear and give your product manager the space to work with their team to work out how to deliver the results you need.

Posted on

How to create review apps in Heroku from Gitlab

A review app is a temporary application created to help you review in-progress code changes. You’ll use a review app because you’re working on a code branch and want to see what the changes will be like in a production-like environment, or because you’re reviewing a pull or merge request from someone else.

Gitlab doesn’t explicitly outline how to setup review apps with Heroku, but the Heroku API is well-documented, and it’s quite straightforward to get this up and running. You’ll need to set up a few environment variables. And make sure that the length of your branch name and your project name is no greater than 29 characters (heroku has an app name length limit).

To create a review app:

  1. The interesting things happen inside (Inside start_review_scripts.bash)
  2. Create a new app with a URL derived from the name of the code branch
  3. Get the right git branch, then push it to heroku.

YAML section on creating a review app in heroku via its API

To delete the review app:

  1. Delete the app

code snippet to stop review app. Use the hyperlink to access the full snippet

View this build pipeline in full.

Posted on

Camp Digital 2018

A summary of the talks I attended at Camp Digital 2018 at the Royal Exchange Theatre, Manchester.

Ending It. Emotionally, Responsibly, With Your Business Intact – Joe Macleod

With death becoming less visible in society, we expect perpetual heavenly consumption.

Consumer narrative structures are unusual in that they don’t have endings.

Consumer packaging often avoids recognising the real end of a product. So people generally aren’t aware of the fact that they can recycle old electronics.

Designing for endings and multiple engagement is a good idea:

  • Permitting no fault divorce reduces suicide.
  • Even the best gyms have 30% of people leaving per year. So design a good ending experience to get people back later on if they’re a serial gym-leaver.
  • 50% of new financial product consumers leave within 90 days.
  • 71% of app users stop within 90 days.
  • GDPR and the right to be forgotten empower people to initiate endings. How might you make it easier for that person to come back? (GDPR is generally thought of as about privacy and data. But it’s also an opportunity to design for endings, and tidying things up.)

Designing from the perspective of novelty is bad:

  • The promise of novelty:  New process, materials, products -> an improved life.
  • Not sustainable.
  • Fails to provide individual reflection about consomption. Doesn’t acknowledge scarcity.

Designing from the perspective of endings is better:

  • Design something from the perspective of the end of its use.
  • Plan for recycling and for repeat use.
  • Reclaim resources
  • Reflect on consumption
  • Develop and design new things.

What does a good closure experience look like?

Consciously connected to the rest of the experience through emotional triggers that are actionable by the user in a timely manner.

Some well-designed ending experiences:

  • Epson’s PaperLab gives a visible ending and rebirth as it devours old paper and makes new paper.
  • Marie Kondo’s Tidying Technique includes a thankful, meaningful goodbye to things that we have consumed.
  • Fair phone lets users access their phone’s insides and update it.
  • Kia cars plan for death in 7 years. This opens up the chance for them to sell more.Increase in market share from  1.3 to 3.5% due to the 7-year warranty.  No change in design or price point.

Navigating the ethical minefield of digital design – Per Axbom

We’re hearing a call for ethics because people are being harmed by digital.

Some examples of design hurting people:

One terminally ill person shared their prognosis on Facebook, but Facebook didn’t show this update to their friends. Their friends had no idea they were ill. They probably died thinking that no-one cared.

Grindr exposing HIV status to other companies.

Of people who are getting hurt by design, mostly it’s happening unknowingly.

Can you map out the 1st, 2nd and 3rd order effects of your work?
Eating chocolate is good in the moment, but has negative 2nd and 3rd order effects. Exercising is the reverse. How do you prioritise between them?

Good Inclusive Design is changing how we deliver public services – Katy Arnold, Head of User Research, Home Office

How to do it:

  • Hire people with access needs
    Diverse teams are more likely to design well for diversity.
  • Dedicated people and time
    Even if you don’t have budget. You might need to do it on top of the day job. Build networks with different organisations and groups to help you recruit users with different accessibility needs. As soon as you can, dedicate money and people to design.
  • Set a high bar
    e.g. “include 1 person with an access need in each round of user research”. This has helped push contextual research, as you want to test in context with a user’s own devices and setup, not just in a lab environment. It also makes you think about ethics, consent and data protection. So the Home Office team joined the Market Research Society and got their researchers tested.
  • Support innovation
    e.g. Home Office sharing posters with accessibility tips.
  • Leadership
    Provide cover for good work. Set expectations . Reinforce the approach. Give practical support.

Building a new digital culture – Eve Critchley, Gareth John

The team wanted to move “From helpdesk to strategic partner”, and to encourage people away from tactically chasing individual pots of funding.

The team asked “What’s the biggest problem we need to solve?”
Mind is good at information provision. But next steps for information-seekers to take aren’t always clear. This is the most important problem to solve.

3 goals:

  1. empowering information at all touchpoints
  2. marketing and income generation
  3. using digital to improve the way the organisation works

Some tips on getting colleagues on board with change:

  • 1:1 at the start of the transformation process helped understand pain points and desires. This seeded future conversations making the case for change.
  • These champions were cultivated over time.
  • Competitor research, including out of sector. But you don’t want to go too far with this because each charity serves a different set of user needs.
  • Opportunity cost and ROI are useful frameworks to build shared understanding.
  • Some pieces of collateral or public decision-making act as boundary objects.  They render the project visible and intelligible to people on the outside and help them feel involved.
  • Build buy-in incrementally.
  • Storytelling helps.

Tech, polyphony and power – Ella Fitzsimmons

“You can’t control the story anymore, but you can choose what to emphasize”

https://twitter.com/AmyMcNichol/status/991691656025034755

Stories are political

CIA sponsored abstract expressionism, to boost American soft power, combating USSR’s Soviet Realism.
Abstraction was interpreted as about being a space for free, Western individuals. Societ realism showed lots of people working joyfully together, implicitly focusing on social confirmity.

The Iowa Writers’ workshop was also sponsored by the CIA. Individualistic, senses-driven, narrow, quirky, materialist, warm stories. Not about systems, ideas, injustices or castles in the sky, which was more the USSR style.

Most of the stories we tell today are about heroes

In the hero’s journey narrative, tech startup garages are the liminal or otherworldly space.

The heroes journey narrative for tech sector is:

  • kind of an outsider (A bit of a lie – rich and well-educated)
  • uniquely gifted (See above)
  • moments of doubt
  • perseveres
  • returns with the elixir

What happens when a heroic CEO is the centre of the company’s vision and what it builds?

It encourages certain kinds of personalities and behaviours, and the centralisation of power. It bleeds into the rest of your work – e.g. your software. It also leaves the organisation vulnerable, and shapes unrealistic expectations of a single person.

What can we do to change this?

  • Change the stories, bring new people in.
  • Amplify different voices.
  • Show individuality without setting people up as heroes.
  • Start to tell stories about many people.
  • Facilitate other people telling stories.
  • Shine Theory.  Amplify the ideas of other people to start raising expectations.
  • Who is quoted matters. Don’t just quote heterosexual cisgendered white men.
  • “Attribution is a revolutionary activity”. Show the community of people that you are part of. Disrupts the idea of lone genuises.

Scenius – the genius of the scene. Jobs: “Great things in business are never done by one person. They’re done by a team of people.”

  • Show what people do, not just what they look like.
  • Ask, ask again, and offer support.
  • Talk about money, both with people who are like you, and with people who aren’t
  • Mix up who works on important projects
  • Ask someone new to do the boring work.
  • Give people time to prepare for presentations

Posted on

How to add MIDI drums to a Cubase track

A quick guide to adding MIDI drums to a track in Cubase. Works with or without an external MIDI controller.

Add an Instrument track, and select HALion Sonic SE.

Choose a drum kit using the dropdown in the first channel.

Close this window.

If you’re using a MIDI controller, make sure that it’s plugged in and that the input is set to your MIDI input, if you’re using one. (e.g. an AKAI LDP8 in my case)

(If you’re not using a MIDI input you can still record drums, either with the on-screen keyboard or by drawing/writing the notes: create a blank track using the pencil, and then click on it to open up the note editor. But do that after you’ve set up a drum map, to make your life easier.)

Now set a drum map on the left-hand panel – GM Map.

This replaces the generic MIDI piano roll with named parts of the drum kit – much more useful. It also shows which MIDI note they correspond to.

Before setting a drum map:

After:

Open the HALion Sonic window up again.

Add the same drum instrument in channel 10 of the HALion Sonic
If you don’t do this you won’t get any sound after adding the drum map. (I have no idea why.)

Now you can either record live through your MIDI input, or you can program some percussion via your mouse.)

Bonus – change which notes your external MIDI device sends to Cubase

The following instructions are for my AKAI LPD8 but are probably quite generic.

Open the LPD8 Editor (a separate programme).

Create a new preset with the notes you’re interested in from the drum map.

Then save it and press ‘Commit – Upload’.

It’ll now be on your LPD8, ready to use in Cubase.

Posted on

Designs of the Year, and Print in the Digital Age

Here are my highlights from the Designs of the Year exhibition at the London Design Museum.

Warka Water

A 12-metre tall bamboo tower that gathers water rom the air. About 100 litres of clean drinking water per day. Inspired by lotus leaves and spider’s webs,
The project is named after the Warka tree, an Ethipian fig.

Refugee Text

A text chat-bot to give refugees trustworthy information on their phone.    

Refugee Nation Flag

Being stateless makes it hard to access rights, and being away from home makes identity and belonging more difficult. But creating a nation through a flag gives some identity, coherence and hope.

Mrs Fan’s Plug-in House

Designed as an upgrade to the historic hutong districts of Beijing, this pre-fabricated house slots in to the existing courtyard structure. It should be affordable so that existing residents can stay living there.

The renovated Sala Beckett Theatre

The building was previously Barcelona’s Peace and Justice Cooperative Building. Some of what was there what been retained – the bare plaster walls, exposed timber and rose windows – but many things have been added.
I enjoyed the playful sense of remixing the past, of function and style shifting  over time. In its confusion it feels alive with possibility.

There were some interesting items here – but I did wonder if the exhibition should shift its focus towards designed things that go beyond the physical. Refugee Text was an example this year (and GOV.UK in the past) – but what about great services, concepts or algorithms?

Print in the Digital age – redesigning the Guardian newspaper

The concise popup on the Guardian’s new tabloid format was worth a quick visit.

I’d assumed that the new tabloid format was primarily about saving money on printing costs. But it was also an opportunity to re-design the approach to preesenting printed information. Digital content design has now influenced print desig. Writing and formatting is intended to facilitate scanning, with fewer blocks of text. Infographics are used more too.

Compare the two ways of presenting a single article in the images below:

 

 

Posted on

Sources of insight and inspiration used by GOV.UK Product Managers

A list that came out of a GOV.UK Product Manager community hour I facilitated recently.

Blogs

Putting people first

Inside Intercom

Nielsen Norman

Mountain Goat software

John Cutler

Melissa Perri

DEV

Mind the Product

Product Hunt (also, the Product Hunt browser extension)

GoSquared

Silicon Valley Product Group

Pivot Product Hits

Books

About Face – the principles of interaction design

The Little Black Book

Step Up Club

The Design of Everyday Things

Podcasts

Aurelius Lab

This is Product Management

99 Percent Invisible

Intercom

Video

Product School video AMAs

Reading lists

Simon Cross’s PM essential reading list

Attack with Numbers

Ross Ferguson’s PM reading list

Exhibitions

Design Museum’s Designs of the Year

Royal College of Arts, Show of the Year

Events

Product Tank Events

Lectures, e.g. psychology

Formal guidance on the PM role and product lifecycle

DDaT skills they need – different levels of PM

GDS Service Standard

Service manual

Braun – 10 principles of good design

People to speak to

Other Product Managers

Other teams through internal show and tells

Other Product Managers on a shared task, e.g. working through 52 weeks of UX together.

Other organisations’ open roadmaps

Trello

Monzo

Newsletters

Exponential View