Martin Lugton

Tom Loosemore was interviewed by the Parliamentary Science and Technology Committee on 27 November 2018. Tom was Deputy Director at the Government Digital Service 2011-15. He has a good reputation and I wanted to hear what he had to say. I found him an articulate, expert and passionate advocate of doing digital properly. I pulled out a few notes that struck me.

He described Martha Lane Fox’s report on digital government as “deliberately a very large stone thrown in a fetid pond”.

What is digital?

“It’s as much about a way of working… the notion of working in small teams, working in multi-disciplinary teams, bringing the technology and design skills back into government to be able to deliver in the same way that Google, Amazon, AirBnB and the best startups deliver.”

“Multi-disciplinary, iterative, incremental, constant improvement, feedback loops, embracing open source as a way forward, communicating openly.”

“Ownership by civil servants of the iterative multi-disicplinary design of services, embracing policy, operations and technology”, focusing on user needs not government convenience.

“We are still in the foothills as a government of adopting internet-era styles of delivery. The humility to start by accepting that you don’t understand what citizens actually need and want and that you iterate your way humbly towards getting the policy outcome you want, rather than pretending you know what the answer is upfront. That is a fundamental change.”

Spending and spend controls

Now that GDS doesn’t have spend control, the GDS service assesment process is like having some “birdwatchers” turn up. (Implicitly toothless and irrelevant.)

“There’s a bit of carrot in the Service Standard. There’s no stick. And you need a big stick”

Treasury doesn’t really understand spending:
“You’ve got a Treasury that likes to spend capex on big projects. It’s easy. This world isn’t about capex it’s about teams. Investing in teams who continually improve and develop.”

What would Tom do if he had the power?

• Change the way that Treasury controls spend. Move from a capex to opex model. “Fund teams to deliver outcomes that minsters want, rather than big capex spend like we’re building a motorway. We’re not building a motorway, we’re building services.”
• Champion non-stop the work of mid-level teams across government doing great things.
• Reinstitute IT spend control

We need horizontal government. Ministers for things like payment or personal data. Platform-based, like internet-era companies, with individual services built on top of that.

Do we just need to get better at writing specifications?

“If you think you can write the answer in a specification and get the right answer, that’s the problem. It’s about my capex to opex point. I still think far too many bits of government think they can design the service upfront in a contract. And then your big suppliers are more than happy to deliver it to you. And when it doesn’t work they’ll charge you change control fees through the nose. That was the business model – you charge for change. You pretended for certainty upfront. I think there are still to many bits of government that would like to think that we can write a specification and get the answer we want, rather than take the harder path which is to start small, iterate, based on reality, with a team and accept the fact that we don’t know the answer upfront, we’re going to iterate our way towards it.”

What is Assisted Digital?

There will always be people who won’t or can’t use digital services:

• Access
• Confidence
• Skill level
• Language
• Literacy

When government started creating new online transactions, digital services were created, with offline ‘Assisted Digital’ support, so that in theory no-one was left behind and unable to access services.

Why did I want to learn about Assisted Digital?

Assisted Digital is something that Product Managers are supposed to know about. The DDaT capability framework says that a good Product Manager “Understands the importance of assisted digital” and that a good Senior Product Manager is “Able to identify and implement solutions for assisted digital.” I didn’t know much about it and wanted to learn.

Assisted Digital is the 2nd most searched for content in the service manual. Not having a good Assisted Digital approach is a common reason for services to fail service assessment. Most importantly, it’s my responsibility to make sure that this is taken seriously. This fits with our design principles: “This is for everyone” and “Build digital services, not websites”. I’m not currently working on a service, but it’s likely that I will be at some point in the future so I want to be ready.

So I did some reading and spoke to some knowledgeable and smart people, including Roxanne Asadi and Ben Carpenter at GDS, who’ve both spent a lot of time working on and thinking about Assisted Digital.

How well is government doing with Assisted Digital?

In general we’re not doing a great job. Recent Inclusive Services research showed that Assisted Digital channels “are the most likely to be needed by the most vulnerable users, but are the least likely to be switched on or user-centred”.

The narrow language of “digital by default” and “digital transformation” often led to a narrow view of service design that saw Assisted Digital as of lesser importance.

Tom Loosemore, co-founder of the Government Digital Service, reflected on Assisted Digital recently:

Allowing the notion of – the phrase, even – "assisted digital" to exist was my worst strategic errors.

— Tom Loosemore (@tomskitomski) September 17, 2018

“I could have avoided the need for using the phrase “assisted digital” by making it clear that we should be using Internet-era service design to reach all users, regardless of channel.”

“by separating out “assisted digital” as a different thing, and by handing responsibility for it over to a separate team, we as leaders of GDS created an artificial divide in both our language and our actions.”

“Rather than challenge the “one size fits all” approach to service design, the words “assisted digital” suggested that one size for all was just fine, and that people with additional needs could or should be “assisted” to navigate a single path, common to all.”

And Assisted Digital options are needed by lots of people. For Personal Independence Payments, 50% of users were using Assisted Digital.

How might we be better at Assisted Digital?

• Refer to ‘Service Design’ rather than ‘Assisted Digital’. This makes it clear that this is integral to a holistic service, and not a bolt-on. Focus around the user’s needs and end-to-end problem, rather than the mechanics of the service that you’re offering. This seems like the single highest impact strategic move you can make.
• Include Operations people in designing services – not just Digital people. Otherwise we prejudice ourselves towards digital only, and don’t think about the other channels and implicitly reprioritise them. In government departments, often the Operational people and the Digital people were/are separate teams and directorates. So it wasn’t/isn’t easy to get them to cooperate.
• Include non-government interactions in your service design
• Create and share design patterns for Assisted Digital. It should be as easy to reuse designs for a non-digital interaction as it should be to copy a front-end component like a button on a website.
• Make sure you understand the needs of all your users deeply, including people who don’t have skills and access to digital. If you take this as your foundation you’ll likely do a good job.
• Iterate and test your Assisted Digital offering just as much as you do your website.
  
  

Some changes that leaders can make:

• Think more broadly about the goals behind our service design, and the metrics we use to measure the success of services. If we just judge services on how many people they’ve moved online, how much they’ve reduced the headcount in a call centre, and reduced costs, then we aren’t giving teams licence to take Assisted Digital seriously.
• Don’t just build teams of digital specialists to build a digital service. You need operational people as well.
• Accept that Assisted Digital has a cost. Plan to invest some of the money you save from channel shift to digital in Assisted Digital.

Examples of services with good Assisted Digital

Rural Payments. Offered drop-in sessions and home visits. These were cost-effective as they were for a small number of people.

Student Loan applications. They found out that about 5% of users needed support. They mapped out how the call centre would take calls and help people, and tested it. They triaged calls and offered a visiting service. The volume was very small so they could pay for this – they just had to retrain people at their existing contact centre.

A few months ago Imeh Akpan ran a session for GOV.UK Product Managers going over the Jobs to Be Done Framework. She’s been looking into how we might use it to think about our users better.

Jobs to Be Done is about understanding the underlying problem.

What’s the differnece between a Job and a Problem that a user has? It adds context: so it includes the fact that someone is driving to work, rather than just being hungry.

This kind of contextual understanding helps you improve your product to better solve some known jobs.

So in the case of selling milkshake to people visiting a fast food restaurant, optimising the product in its own right – making it chunkier or improving the flavour – was missing the point. When the business started solving for the underlying problem – the real ‘job’ the milkshake was being ‘hired’ to carry out – then sales went up.

Jobs to be Done is about user motivations and situations, rather than attributes and characteristics. This is good because those things change, and may not be important. ‘Specialist’ users of GOV.UK are often not very different to ‘Mainstream’ users. I found the same thing at NDCS – the imagined differences between “Professional” and “Parent” users didn’t really hold up to scrutiny.

A Job to be Done is the real world goal that the user hopes to accomplish. It’s not a task – those are the steps that someone takes to accomplish the goal, because they seem like the best way of doing so.

A ‘Job story’ is written in the form:

When [situation]

I want to [motivation]

So I can [expected outcome]

Take a Job and a Job Story, and you have a Job to Be Done. The Job stays the same, as it’s a deep undelrying need, but the story and the solution can change over time.

High-level Jobs to be Done on GOV.UK

Do a thing

Life circumstances require you to interact with government

e.g. You want to become a childminder, drive a car in the UK, become self-employed or fish in UK waters.

Trigger: change in circumstances.

Steps:

• Decide where to get guidance
• Discovery loop (find -> read)
• Make choices
• Fulfil legal obligation

Advise on a thing

Help others to understand / interact with / use government structures / policy

e.g. help mum get her pension; help a client understand their visa options

Trigger: client request

Steps:

• Understand client circumstances and request
• Choose the information source (Policy, Data, Regulation, Legislation)
• Research loop (Find / Evaluate / Assess)
• Advise (Explain, report, clarify)

Interrogate / change a thing

Examine, influence, appeal what government is doing and the decisions it has made.

e.g. Appeal my parking fine, raise public awareness about welfare reform, push government to improve policy-making or change policy.

Trigger: Emergency events / data / being told to pay a fine / refusal / minsterial announcement / news / topical events.

Steps:

• Decide information source (generally data and policy papers)
• Research loop (Find -> Evaluate and assess)
• Decide (Support / challenge / prepare for the change)
• Engage (Consultation / campaign / in-person meeting, complaint, appeal)

Location: London
Current Gig: Senior Product Manager, GOV.UK, Government Digital Service.
Current mobile device: Samsung Galaxy S8
Current computer: At home: A self-assembled desktop from 2014, optimised for quiet acoustics and now with a 1070 graphics card, or a Asus ZenBook UX305CA laptop. At work: A 13″ Macbook Air.
One word that best describes how you work: Spiritedly

First of all, tell us a little about your background and how you got to where you are today.

Disclaimer: When you’re applying for a job you spin this stuff into a coherent story.  Certainly there are threads you can follow, but the first part of my career was a series of improvisations and desperate expedients. After a few years I’m now in the fortunate position of being in control of where I want to go, and doing a job I love.

When we were around 9 years old, my mum and dad were dead against me and my twin brother getting any sort of games console. We learnt our times tables and got a family computer. (I later found out that they were planning on getting a family computer anyway…) Me and my brother played lots of computer games together. Starcraft, Little Big Adventure 2, Heroes of Might and Magic, Unreal Tournament. This probably trained my brain to be methodical and be confident in understanding systems, and sold me on the merits of shared exploration and adventure as only one person could play at once.

I went out-of-town to a grammar school in leafy Bucks, and was fortunate to learn HTML. I built my first website on freewebs, about Grand Theft Auto 3. The site had neon text on a black background, character skins that I’d customised myself, car mods, a hit counter and way too many popups. I desperately wish I could share it with you but it seems to have been scrubbed from the face of the internet. Beyond computer games I didn’t really have the confidence, knowledge or interest to dive deeper into what computers could do so this thread lay slightly dormant.

Having originally assumed I’d wanted to do a PPE degree, I decided that history was more my thing. It’s varied, has lots of interesting stories, and is all about people living through whatever situation they find themselves in. I tried my hand at economic history, political history, social history and cultural history. Turns out I really enjoy cultural history and medieval history.

In hindsight this degree was exemplary training to be a Product Manager – you have to rapidly master a new topic and communicate clearly and confidently about it. It trains you to be a bit of a renaissance person, interested in diverse things and with a bit of a sense of adventure. I spent hours each day in studious solitude in various libraries, but also spent a couple of hours each day in excellent conversation with other people in my college over lunch or dinner. That ability to dive deeply into someone’s domain of expertise and get to know how it works, what they care about and what they find difficult, was drilled really well by this.

During this time I assumed that I wanted to be a museum curator. I’d done a bunch of volunteering at the London Canal Museum, working on stuff like an audio tour of the walk from Camden Lock to Islington Tunnel, and a series of audio installations in the museum. In the summer before my final year at uni, I remember a chat with the chairman who advised me that there weren’t really any jobs to be had in the sector. I also reflected on the demographics attending museums and thought that I might be able to have a wider impact doing something else. But I wasn’t sure what that was.

This was a useful if poorly-timed rethink. I left uni without a real plan. I applied for lots of things, including being a radio weather reporter. I came within a hair’s breadth of becoming a trainee television creative, coming up with gameshow concepts. (Apparently some of the concepts I pitched were a bit high-brow. An acceptable rejection.) I nearly ended up working in policy in the charity sector, which is what my twin brother does now.

I’d done a fair amount of digital communications for university societies, just as social media was taking off. A meetup with an old teacher of mine, now working in medical education, pointed me in the direction of an opportunity to use these skills on the creation of an online learning community for training doctors. It felt like a break so I packed my bags and moved to Kentfor the contract.

I didn’t know about agile, or about user needs or iterative design at this point, but I gave it my best shot and started learning more and more about how the different parts of digital fit together. I was working on all aspects of the site, alongside a developer, so built my understanding loads. My manager was excellent at helping me understand the politics as well.

From here I did digital projects and digital communications jobs for a while. I remember one early job, finding out that a ‘web editor’ role in practice needed a firm technical understanding of how website backends worked. I got in touch with my friend Andy Jones, and he talked me through everything in a call that same evening. If ever I’ve been generous with someone else in helping them understand something technical, believe me when I say I’m just paying it forward.

I moved around quickly, much of this as result of the financial crash and funding cuts causing difficulties for the charity sector. Admired GDS since 2013 and was delighted to join in 2017.

Take us through a recent workday.

A standard weekday starts with a half-hour checking up on emails and Slack before a standup with the first of my teams at 09:45. We take ten minutes or so to run through work-in-progress, coordinate activities and discuss any blockers. I repeat the process at 10:00 with my other team.

As a Product Manager my job is about making sure that we’re solving the right problems, that we’re adding as much value as possible, and aligning around the right vision. Day-to-day this means that understanding, assessing and communicating purpose is my role. So I’ll be making value judgements on how to approach certain areas of work – whether to gold-plate a feature or do something basic, for example, or which from a set of options to work on – either with my team or solo. I’ll spend most of the day going from meeting to meeting – which sounds ghastly, but actually is a series of interesting chats with intelligent and motivated people, diving deep into interesting problems. I love working with the different specialists in my teams, and it’s a real brain workout. I do sometimes regret that I don’t carve out more time for solitary intellectual activity, diving deep into a puzzly problem, but if I had to choose, I’d take the group approach every time as it feels more dangerous and collaborative.

When I’m at my desk, I’m usually doing some form of written communication with someone not in my team – a user or stakeholder in another government department. There’s an interesting tradeoff here between ruthless prioritisation of your time, and maintaining relationships and being diplomatic. As a Product Manager, lots of people want your input, or for your to do something for them. So you also spend a lot of time politely saying no to things.

We pause our working day at 3:45 for 15 minutes to have fika – a break for coffee, cake and a chat. (Sometimes just the final one). The key thing is that it’s a non-work environment, so we have an actual break and people can get to know each other.

What apps, gadgets, or tools can’t you live without?

I feel at home wherever my desktop computer is set up.

I put a lot of value on having something that can play music.

What’s your best shortcut or life hack?

Sometimes not doing a thing is the best approach.

Take us through an interesting, unusual, or finicky process you have in place at work.

I insist that every card on my team’s trello board has a ‘What’ and a ‘Why’in its description, so that anyone can understand the purpose of the work. “Can you get a What and a Why on that?” has become a sort of joke catch phrase but I’m okay with that. It makes sure that everyone in a multi-disciplinary team understands the purpose of everything that is being worked on, and it trains people in communicating beyond their own specialism.

How do you keep track of what you have to do?

Google calendar for solo tasks. Trello cards for things I’m working on with my teams.

I’ve tried the Getting Things Done framework, but when things get busy I’ve found it too brittle.

I take notes of  things to do on post-its and stick them to my laptop. I triage them to something electronic within the hour.

What’s your favourite side project?

My Social Summary. I built it from the ground up (that’s why the front-end looks rubbish ;)) and I learnt loads. It’s now a paid-for product. For £3 a month you get a daily (or twice daily) summary of the best material shared by your twitter network.

I’m also proud of the technical work I did on a creative project with my ex-girlfriend. I set up most of the standard things that a competent developer would do: version control, automated testing, a decent build pipeline, programmatic creation and destruction of review applications. The product idea was a fun and interesting one, and I got to play around with a few different APIs.

What are you currently reading, or what do you recommend?

For work-type reading, I’d recommend “Turn the Ship around” by David Marquet. It’s about intent-based leadership and how you can give people space to do great things. In knowledge work you need to lead this way, not in a command-and-control fashion.

The novels that have impressed me most as an adult are probably Nabokov’s Pale File and Paul Auster’s New York Trilogy.

Who else would you like to see answer these questions?

Some of the Lead Product Managers and Heads of Product at GDS and across government.

What’s the best advice you’ve ever received?

“Time’s short, your life’s your own. And in the end we are just dust and bones.”

“Work smarter not harder”

“Love is letting go of fear”

“Just Fucking Do It”

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.

The inimitable @cagan giving us a chat on achieving extraordinary things with ordinary people. #ProductPeople pic.twitter.com/YDk18lukHh

— Steve (@stevenjmesser) October 19, 2018

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”

Marty Cagan's reading lists of books about empowering teams – and yet it still doesn't happen. Why not? Lack of trust. #ProductPeople pic.twitter.com/VckPBG1t6O

— Emily Labram (@emilylabram) October 19, 2018

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.

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.

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.

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.

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.

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.

To delete the review app:

1. Delete the app

View this build pipeline in full.