Month: April 2018

As a part of my continued strategy for working through my professional angst, about whether I’m a product person, a UX person, a developer, or whether it’s all about competencies rather than roles in cross functional teams, I’ve got into the ResearchOps/ReOps community in the last few weeks.

If you’re thinking “What is this ResearchOps thing?”, and you’re in Berlin, then this post is for you.

First, backstory

Over the last few years, I’ve been working remotely and onsite with a number of non-profit orgs, and startups.

While I’ve often written code, or deployed stuff, a large part of this has involved me trying to help them operationalise ways to reduce the risk of what they’re building by using research techniques to make sure the we are building the right thing, before we get around to talking about building the thing right.

This has typically taken the form of:

building personas with the teams in ways that invite change and validation of their key characteristics

buddying up with team members to carry out research together

coming up with repeatable, streamlined processes for research to book interviewees, find research buddies, and capture observations in a way to make findings easier to locate, digest and act upon

This has typically been a mix of remote and onsite work, but because clients have other remote staff, I’ve been thinking a lot about how to do this when you don’t have shared wall everyone walks past.

Finding ResearchOps

Last month, I saw Kate’s Towsey tweeting about something that sounded like she had been trying to solve some of the same problems – in particular, making research easier to integrate into the process of bulding services or products:

I've started a ResearchOps Slack channel so we've got a place to share, learn and be geeky about #userresearch operational stuff. Let me know if you want to join. #ResearchOps

Over the last few years, I’ve signed up to a number of slack communities (38 at the last count…), and set up a few myself. I dropped her a message, and and asked about helping her streamline the sign-up process so she wasn’t going through the same twitter > slack invite email loop umpteen times a day.

Okay, what is this ResearchOps thing?

Right now, there’s no concrete definition, and it’s not clear that there will be canonical one, a la devops.

And like devops, I think the conversation about avoiding silos, scaling research practices so work isn’t ‘thrown over a wall’, making research easier to use across an organisation, and working cross-functionally is more important than a single holy definition.

Similarly, I think there’s value in having a name for stuff, as saying researchOps is just a part of Product Management, or UX Design, for me, is a bit like saying devops is just part of being a Full Stack Developer.

You might use some of the same techniques and tools, but working in the spirit of devops requires thinking about how your organisation is set up to deliver valuable work in the same way I think working in the spirit of researchOps does.

Saying it’s just part of a something like Product Management or UX runs the risk of not having these discussions about how work is valued in an organisation.

Off my soapbox

Anyway, It’s probably more useful to think about the ideas being covered right now, and this realtimeboard Kate shared offers a pretty good list.

There’s a lot more more context in the ResearchOps slack workspace, but you can comment and ask questions by following the link below:

If you’re in mainland Europe, I’d like to propose something else though.

Thinking about ResearchOps together in Europe

As one of a number of people thinking about ResearchOps I’m working with Kathryn Hing, another Berliner to to help organise the European part of a global set of workshops to explore ResearchOps together.

Specifically this is what we’re wanting to do with these workshops:

give the community the opportunity to collectively explore what we mean when we say ‘ResearchOps’;

share knowledge and stories about how we’re doing ResearchOps today;

give us all the opportunity to express what we need and want from the ResearchOps Community;

and, last but not least, create spaces for us to get to know each other in-person too.

Why we need your help

I’m more of a tech generalist than a specialist user researcher leading a team of other researchers. Kathryn is also a service designer who does design research – so we can talk about some aspects of operationalising user research with confidence, but not others.

If we want this to be a rich conversation, we really need to have people who work primarily as user researchers coming along too.

If this all sounds like it’s interesting to you, please take a couple of minutes to fill out the type form below:

I’ve just finished reading through Charlie Owen’s converted-webpage-from-a-talk thing, Dear Developer. It’s funny, friendly and really captures the wonder of the web as a medium to work with. Without picking fights, it steers developers away from a lot of bad practices, and towards ones which are more empathetic, resilient and performant. In this post I share a few gems that stood out.

The web as a resilient technology

If you’ve developer with the web much over the last few years, you can’t help but notice a trend towards pages becoming brittle. I mean this in the sense that if there’s an error in the javascript, or a resource like a javascript file doesn’t load in time, the page is essentially unusable.

It is this flirty declarative nature makes HTML so incredibly robust. Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run.

Let’s just stop and think about that, because we take it for granted. I’m pulling chunks of code out of a running computer application, AND IT IS STILL WORKING.

Just how… INCREDIBLE is that? Can you imagine pulling random chunks of code out of the memory of your iPhone or Windows laptop, and still expecting it to work? Of course not! But with HTML, it’s a given.

The pyramid of robustness

I really like the visual device, the Pyramid of Robustness she uses for this too

Pyramid of robustness

It’s a deft way of presenting the downsides of building assuming javascript is always working, and there being a fast enough connection to download all the resources on a page quickly:

The Pyramid of Robustness, upside down

There’s a really good visual gag here that made me guffaw in the silent section of the coworking space I was in when I read it first. I won’t spoil it for you.

Getting started with a11y and why it’s important.

There’s a nice part about getting started with accessibility or (a11y) to it’s friends, and how to do this easily on a mac.

You just hit command+f5 to start voice-over, and you can start navigating content the same way someone who is partially sighted, or blind would.

It also covers why it’s important. Accessibility is often mischaracterised as designing for blind people, and as a sighted person, it’s often thought of as the key reason (I’m guilty of this in this section myself).

It’s the right thing to do, but it’s also worth thinking about this in terms of a design being resilient – people can be temporarily disabled when they injure themselves or even when they’re just holding something in one arm, like a bag of shopping or a child. The persona Spectrum from Microsoft is a good example of this.

Microsoft’s Persona Spectrum for inclusive design

When it’s presented like this, it reframes a11y as not being a question of charity or guilt, but being one of pragmatism and professionalism.

Framing it like this in terms of positive, intrinsic motivation makes it feel more likely to be adopted.

There’s a nice quote from Theo Schlossnagle from Circonus that I feel captures this idea – he uses it in the context of hiring, but it’s stayed with me ever since I heard it:

I don’t want programmers, I want professionals.

If we want to call ourselves software engineers and act like we’re a grown-up profession, then we should hold ourselves to the standards engineers and other professions hold themselves to.

And that means to acknowledge the full range of contexts the products and services we create are used in.

Go take the time to read it

I’m when speaking to people who want to learn to code for the web, I think I’m going to point them to this as a thing to read for understanding why the web is magical.

If you haven’t read it yourself yet, I strongly recommend checking it out.

I’ve written previously about GDPR, thinking out loud about running an event called OMGDPR – a community run, unconference to explore the changes to the industry it’ll bring about. In this post, I introduce the event publicly and explain why I think it’s important.

The background – what’s GDPR?

GDPR stands for General Data Protection Regulation – it’s the term used to describe a set of changes to laws governing how data about people can be stored and used, in the EU, but also about EU citizens when they’re outside the EU too.

These changes become law on May 25th across the EU, and this is generally seen as the first time data protection regulation has had teeth.

Why GDPR?

I’ve had to explain why I think GDPR is important a few times in the last few weeks.

If you’ve been following recent revelations about social media being used to sway elections and referenda around the world, and the seemingly endless stream of data breaches and questionable practices around, I think you’d agree the way personal data is used, stored and traded needs to change.

We need an alternative, and industry has consistently failed to regulate itself or provide one, so GDPR is effectively the policy response to this garbage fire.

GDPR is interesting for two main reasons for me.

Firstly – unlike previous data protection legislation from the late 1990’s, it’s not so prescriptive about how organisations should comply with the law.

This is good, as we don’t end up with the silly conversations about cookie law, but bad in the sense that it’s quite as clear when it comes to telling if you’re operating within the law.

Secondly – the penalties for not complying with the GDPR are pretty eye-watering. If you’re found not complying with this legislation, you can be fined up for up to 4% of your organisation’s turnover, or 20 million euros, whichever is larger.

See what I mean about teeth now?

Obviously not every company will automatically be fined these huge amounts on May 26th if they’re not complying with the law, but it provides a very strong motivation to look at how data is handled, that we’ve never had before.

A traditional workshop will focus on spreading explicit knowledge (the codified knowledge on what works best) that is contained in best practice databases and toolkits. The unconference format also uncovers tacit knowledge; what participants have learnt works well in their local context.

So to paraphrase:

When you have a clear solution to a problem, it’s more useful to spread that codified knowledge in the form of talks, workshops, which emphasise attendees absorbing information from an expert.

When you have more uncertainty, and a group of people motivated to solve it unconferences are good for surfacing knowledge about what works, from the entire group.

I’m shamelessly borrowing the image below from that post, as I found it really useful when thinking about this:

Applying this to GDPR and OMGDPR

For the parts of GDPR, that are explicit and well understood (much of it is based on existing practice, which often hasn’t been followed) – there are now loads of people doing the codified knowledge stuff.

Type in GDPR into a search engine, and you’ll find loads and loads of consultants and trainers who can help you now for a price.

For the parts that aren’t so clear, there’s a role for unconferences and similar, hence OMGDPR.

A favour to ask

Typically, white dudes like me and Maik are really well represented at tech events, so I’m pretty sure we’ve got that viewpoint nailed. We’ve also had some success with reaching people who don’t sound and look like us, and nor work in the same context.

But it would be a missed opportunity if we missed out on hearing the voices who are typically marginalised not even considered when tech products are built for mostly white male Europeans and North Americans.

Also, you don’t need to be some technical genius to contribute – we really want a wide variety of voices, as GDPR affects a wide range of people, with different things to bring. If you’re a designer or work with content – for example, then there’s a whole piece about making consent understandable, and how we need to rethink patterns we’ve used before. If you’re more into operations, there’s a whole range of new kinds of agreements that need to be understood and implemented now. If you’re into strategy or service design, there’s a whole raft of new privacy friendly ideas for services waiting to be discussed

An unconference is only as good as who comes to it, so if there are people you’d like to see there, and you think their voice would add to the conversations on the day, please do invite them.

Final note about doing this in other parts of the world

We have a nice venue, and some smart people signed up already but there’s nothing magical about OMGDPR that can’t be replicated elsewhere.

I’ve had a few people ask about doing this elsewhere in the world later in the year. I’m curious about how much appetite there is.

I met Marc when we both worked at Headshift, back in 2010. He’s been a friend I’ve been in touch with the last 8 years or so, and when I heard he had been writing a book about Product Management, and was offering copies for feedback, I jumped at the chance. I started reading it last night, and I finished it today – here’s the write up.

TLDR

A quick snap of Marc’s book

In short, it’s the kind of book I’d love to have come across a couple of years into product management myself. Although it’s short, and designed to be a fast, easy read, Marc covers a lot of ground in this book, and provides lots of useful leads for further reading in the areas that might be relevant given your specific context. Given how relatively young Product Management as a profession is, and how much the job varies from company to company, I think this is a smart move.

If you’re a senior product manager, you will likely have covered a lot of this ground already, but I learned a few things from reading it, and there a few nice names for patterns or behaviours I’m glad I have a name for now, like the product janitor ( more on that later).

What it covers in more detail

While there are some nice summaries of applying Jobs to Be Done, User Stories, (probably the main day-to-day currency of agile product managers), there’s a substantial amount of space in the book assigned to the actually speaking to customers, and users.

Research and discovery for product managers

In particular, there’s a lot here that you might typically the kind of work you might associate with user researchers more than traditional product managers – things like contextual inquiry, field studies, how to do interviews, how and when to use prototyping, and continuous discovery.

The political side of product management

As a product manager, you often have to rely on influence over authority when it comes to getting things done, and there’s an entire section on how to go about doing this from trading in different forms of social capital to manage upwards, downwards and horizontally.

There’s a common trope about product manager’s jobs basically being to say NO all the time, and I think my favourite quote in the book refers to this:

Product management is not like Christmas

In many cases, being the person who says NO all the time, can strain working relationships – Marc introduces a few ways to do this in a diplomatic, collaborative way.

I think this may be one of the most valuable parts of the book if you’d ever had to say NO like this, and experience the fallout it can bring.

He does this by showing examples of expanding a conversation, from straight yes/no feature request, to a richer one that lets the requester understand the trade-offs and costs they’re asking someone to incur when they want their pet feature.

He shows how to use cost of delay, opportunity cost, and incurred maintenance costs of building a new feature to help them understand the true cost of their request, along with ways to structure the conversation to give them a way to pursue it further if it’s truly valuable.

One phrase that was new to me, that I’m going to take with me was the idea of a product janitor – given how poorly defined product management can be inside organisations, it’s often the case that all the jobs that aren’t being done end up falling on the lap of the product manager, from scrum mastering, to bits of delivery work, like UX design, and so on.

This can mean that there’s no time for the strategic, customer facing, or commercial aspects of the job. It’s useful to have a name for this concept, as it’s depressingly common.

What it doesn’t cover

While there’s a fair amount about creating product vision, looking at trends and market size, there’s less than you’d expect about creating and sharing roadmaps. That said, this may be a function of this being something a more senior product manager would be expected to be responsible for, and this book feeling like it’s aimed at early to mid career product managers.

Also, while he mentions cost of delay in a number of places, I came away with the impression that if I hadn’t been introduced to it already, I’d want more of an explanation of the concept. Again, I can see why you might shy away from it, as while it’s powerful, it can be counter-intuitive, and confusing.

Also, while this assumes some flavour of agile development is the environment you’re working in, it doesn’t go into too much detail about how to make this fit into scrum, kanban or some variant.

When I read it, I got the impression there was an implicit scrum master, agile coach, delivery manager or similar taking care of process and making sure regular releases happened. This is probably a safe bet, as it’s not typically the product manager’s job (see product janitor), but if you’re in an environment where you’re having to think about process a lot, the book is focused on the why and what of building, but not the how.

Well titled, well structured

It’s hard for me to be objective, given that Marc is a friend, but, if you’re a few years into a product management career, and starting to feel like you know the ropes, I can happily recommend this.

It’s a fast read, you’ll be reassured by the examples of applying what you already know and do in other organisations, and you’ll pick up a few useful techniques to use in your day-to-day, as well as a lot of useful ideas to investigate as you grow.