Assisted Digital – what it is and how to do it well

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:

“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.

Jobs to be Done on GOV.UK

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)

This is how I work

Location: London
Current Gig: 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”

“Just Fucking Do It”

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.

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.

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.

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.

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.

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.

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”

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