100 days at Scope – shifting from UX to Product Management

Today marks day 100 at Scope for me, so I thought I’d reflect on the past months and some of my work, and the result are three challenges I faced transitioning from UX design into product management:

1. Launching a web app with no launch date

As part of our strategy to become less mobile-centric, the first big task was to launch the new web app. For this we already had an information architecture and a visual design.
What we didn’t have was a launch date. Anyone dealing with scoping an MVP will be familiar with the challenge to decide which features to go live with and when: what should be there right from the beginning in order to make a good first impression, and what can we release later based on some system of prioritisation? In my UX roles I had been involved in breaking complex features into user stories and prioritising them, but it was always to someone else’s deadline. So I kept building and grooming the feature set, and would probably still be fine tuning the design. Thankfully, our CEO Peter jumped in and set a date to go live, and we did (launch blog post, in German).

As Head of Product I am now responsible for planning and driving the release dates, and focusing too much on the design is probably going to distract me.

2. Conducting user interviews when everything else is super urgent

I believe in user-centered design. I have developed a hypersensitivity to UX designers who never observe users or think they are an expert after interviewing five people, two of which they are related to.

So, obviously, I wanted to go out and talk to users as soon as I could. Yet there was so much to design and improve, and working part-time meant I was falling behind and becoming a bottleneck. So how can I research a better security system while the bank is being robbed upstairs?
By insisting on what I have been teaching for years in workshops and classes: base features and design on what the users need. If we are not solving one of their problems, then we are likely to run in the wrong direction. And for this, we first need to understand them.

In our case I started with the supply side: our wise, witty and always-busy curators.
Over Google Hangout, I engaged with nine carefully selected individuals, who let me observe them and explained their issues when selecting and commenting articles for us. The conversations gave us valuable insights about their motivation and pain points. This now forms the basis for prioritising the much-needed work on the “curator console”, the application they use to deliver articles to you every day.
Users, you’re next! (yes, yes, provided I deliver a thousand other things first, those robbers are still upstairs. Luckily our new design intern Ioana is starting to keep them in check.)

3. We’re a startup, but we are a brand new team using stuff someone else built

My banking colleagues down under at ANZ are going to cringe when I use the word legacy for 3 year old software (“Legacy? go check out our green screen, non-GUI core systems from 1962 and we’ll talk again.”).
I am going to do it anyway: Taking over legacy apps and interfaces is tricky, at Scope I met

• Complex technology – a beast of a crawler that delivers articles to our curators. It contains many unknown features and snippets of code that would deliver enough material for another episode of x-files.
• A pretty much finished visual design for the new web app and drafts for a redesign of the mobile app. It’s always delicate to come in as a UX Designer when a lot of interaction and visual design decisions are already made.
• Two mobile apps are happily being downloaded from the app stores every day. And they look completely different to our web app…
• Several newsletter that are difficult to distinguish between

Going through all the different features and designs, instead of adding more stuff, we first focused on removing a lot of things (or “Killing the zombies”, as Lisa Long described it in her brilliant talk at the Product Management Festival last month).

The challenge was – of course – to decide which ones should go. For this, we established these basic rules:

1. If we suspect no one needs it, we hide it
2. If we don’t know what it’s doing, we hide it or turn it off
3. If we don’t think what it’s doing creates value, we turn it off

 

Let me put this in a graph

So my UX skill set can provide great value to my role, yet also prevent me from doing what I need to do now.

 

I am looking forward to the next months ahead, where we need to focus on user growth and hopefully get a few more corporate clients on board.
Interested in helping me improve the product? join the Mailing List for Scope Improvers where I will post calls for usability test participants or interviewees.
Or you can just email us your feedback at support@thescope.com