Team Roadmap And Planning

Elisabeth Barrie at UXDX Community: Oslo. Video: https://youtu.be/kcZnkewdLTA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Scaling pains at Vipps

[00:00:12] The last year we had quite a big change in how the company is set up, which has also actually had quite a huge impact on how we work and how we plan and what we do. We've gone from being this DNB[?] project, to being a small company, to now being quite a big company. We've gone from focusing more or less only on peer-to-peer payments to now all types of payments as well as identity, and previously[?] only focusing on national competition, well, now all our focus is on international competition as well.

[00:00:54] We are now currently onboarding 10 to 12 people a month, which is, as you can understand, quite a big scaling pain. So how do we create alignment when onboarding so many people every month, as well as developing quite a lot of new features at quite high speed? We want to maintain and ensure this unique position we have today, especially among young people, being the number one most liked brand, even more liked than Snapchat, Netflix, Facebook, Spotify, YouTube, which is incredible, something we never believed would happen. And also we're now planning to go across borders.

[00:01:36] As you can see, it's a lot of things happening, and lots of things happening at once, which really demands a bit more. Two of the things that we try to do to really help us through this quite painful phase of scaling is to have roadmaps, whatever you call it right now[?], as well as trying to empower our teams. So I'm going to go a bit into these two things today.

Mixed feelings about roadmaps

[00:02:05] First, roadmaps. I have quite mixed feelings about roadmaps, which probably many of you do. I've been quite happy, it's bad[?], and I've come up with a lot of different tools. I've seen this search of finding the solution. I think I've tried a lot, and in the end[?] nothing that worked for it. I think maybe nine months trying to gather everyone's roadmaps across twenty-nine organizations and see what are we actually doing. So I can feel your pain.

[00:02:39] At one point we were doing these huge Gantt charts: what are the dependencies, week by week, almost day by day, but at least week by week. We missed all the deadlines. Huge pain, broken promises. So then I actually started: let's just scrap the whole thing, let's do this Kanban agile, not do anything. That didn't really work either, because we do need some kind of roadmap, something to guide us. And I don't care if you call it roadmaps or something else entirely[?].

[00:03:19] So I have mixed feelings around it, we tend to let the priorities really kind of slip away[?]. But we do need something to align the organization, we need something to help us see the big picture, and we need something that the salespeople can bring out to our customers to really get them excited[?]. And I'm not talking about the release plan, I'm talking about communication: tell the story of how we are going to achieve our vision.

[00:03:51] So to me a roadmap is some kind of sequence of different product market fits. It should be a high level roadmap, showing the customer needs, the road you will take to get to your product vision. It should really answer, to everyone who sees it, what we'll be doing, why we're doing it, and how does it help us reach our objectives and key results. I don't really care what it looks like, but these are the two things that are really important for me: that the roadmap should guide us, so high level, and really answer these three questions.

Can roadmaps and agile work together?

[00:04:37] I have to say that I spent some time thinking, can roadmaps and agile really work together? And I kind of concluded[?] that they can, if you do it in a bit different way than at least I used to do them. Because the roadmap to me is more like this high level plan giving strategic context, and agile to me is then empowered teams who can and are able to release in small batches frequently and are responsible for the solution and the results they create.

[00:05:08] So now we went more or less like this, not as granular, something which is divided into some sequences and also shows the road to the vision. We're trying to have in the "now" element the things we really are working on currently, while the next one is things that are maybe just in an exploring phase. We think we will do it, we have some insight that these are areas to handle, we're not sure about the solution, but we might even be working on prototypes in this next column.

[00:05:47] Later, I have to say, it's more vague. We don't really care that much about the impact[?], we think this is a customer need that we need to tackle to be able to reach our aim. I think this has at least helped me a lot in terms of these broken promises, getting people to understand where we are going.

What has to be in place first

[00:06:10] But before you start doing this, there are some things that really need to happen. I haven't translated this one, but I will show another. You need to have a company vision, you need to have your product vision clear, you need to have some business objectives, product objectives, that show what's the end point, how can we reach them for this year and in two years, for example. And that was so difficult for me to translate.

[00:06:40] But these are things we use internally, of course, to build a culture and to get people to remember what we are trying to achieve in terms of which new positions are important, whether that's within e-commerce, within invoicing, to make them really use it to pay and also to be able to be paid[?]. Then we have these two goals on the left, which are the values[?] that we want to nurture, and we think those really are the ones that will help us achieve the new positions. And these new positions will help us to keep, for example, being Norway's best liked brand. So they're very much related.

[00:07:17] Then we've actually worked quite a lot with product principles. This is something we did quite a while ago[?], but it has really helped us now that we're scaling and building a roadmap, to get people and the teams to make more or less the same choices every day, that drive us in the same direction without being very tightly coupled and without having the same person, kind of the product principal, going in and deciding yes or no.

[00:07:47] So here we have four that we think you can probably use ten years from now as well. I think this is very long-lived in terms of the customer: it is easy to use, it needs to be accessible, I need to trust it, and also there's something relating to price. Whether it's something I pay, or if I use my time, or if I give my data away, there is a cost.

Building the roadmap from user understanding

[00:08:13] Based on this we also spent quite a lot of time understanding our users and trying to segment them, and based on this understanding is actually where we build a roadmap. So when we have quite a clear understanding, either by going to a lot of sales meetings or interviewing people, that's when we kind of sketch up the roadmap of which product market fits do we think we really need to tackle to reach the vision[?].

[00:08:42] Then we use this kind of basic matrix to figure out which things are they very unhappy with that are very important for them, and those might be the ones we really then try to go after, and not to go into positions or features that people are quite happy about with the competition, because then they will probably not change their habits. So the ones we put up there are kind of the ones we put into the roadmap.

[00:09:11] But really we had more of this very loose structure. What we have put in lately is more: we clearly put the vision at the top, so that everyone sees it, or at the end, so you kind of see the road. Then we make sure that we put in the objectives. We have these broad time frames, now, next, later, meaning next quarter, later, as well as the user or customer opportunities that are worth investigating.

[00:09:46] So what we end up with is something like this. We have these now, next, later columns, we have the vision on top, and maybe the main objective, like which new position, for example, we're going to take. And then we do a kind of tag, some kind of mark on each of these roadmap cards that tells a bit more about which objective this is exactly, what you need to increase or decrease.

[00:10:12] We also do sometimes: is it business, or is it related to the core, or is it more exploratory? Is it the Kano model, where you have the delighters, you have the performance and you have the very basic features? So maybe for that, nobody does[?], sometimes the team, or which type of theme it's within, so for example this is QR codes. So that we have different ways to also sort through them.

[00:10:42] And then the other one, I know that this is for now, understand, because I give this also to the sales organization, so they show it to their customers and get them very excited and get some people to back it[?]. We also have our disclaimer that this is the plan, this is what we think now, but it might change at any time. And that's been very, very helpful, so this is highly recommendable. It's something we picked up at a roadmap workshop we went to last year. So it's kind of, this is the way we think things are going, but things might change.

Separating the roadmap from the release plan

[00:11:19] But in theory, yes, that is what[?] I think the thing is, to measure success, like which type of users and which teams. But in reality, and sometimes your supporters[?], in reality it's quite messy. If you look further down the list, where we have maybe 15 product teams[?], some work very agile, some are still relating to other companies, so they have to inherit a bit more of a project waterfall process. So you kind of lose this nice feeling of how do we get to the vision.

[00:11:57] So we try to abstract it a little bit higher, because if we look at the other one it gets extremely messy, bigger and bigger[?]. So what we try to do is to really abstract it even higher and higher, so that we have just different levels of the roadmap.

[00:12:16] One thing that we really tried to separate now is the roadmap, which should focus much more on the objectives and the outcome you wish to achieve, and the release plan, which is the teams'[?] more like the chance to communicate what they're doing, which is much more the next release or the current tasks. I think this is probably what the fault was, what I did, that we kind of mixed this together, and that's where all the broken promises and everything came from, because you don't understand the complexities.

[00:12:47] So now we have a big separation: the releases are kind of that lower level, that daily work with the team, and then you have this roadmap of the team, and you can have it even higher up and for the whole company, where we kind of just abstracted and aggregated them and gathered them into just bigger goals.

Empowered teams

[00:13:05] The second thing that we're doing to handle all this painful scaling is to empower teams. I think, at least in the bigger companies[?], if you hear someone referring to IT, you're probably in a company where tech and the product team serve the business. So the business is kind of ordering something and then IT makes it. Well, we're trying to build across the whole company a culture where you have the tech, the product, serving the customers, which then again serves also the business. But it's a very different perspective.

[00:13:50] So for those empowered teams we try to make sure that they have the right competence and passion. This is very different when we hire people and when we put the teams together. They should be able to, or have access to — they should have a product manager, they should have a tech person[?], they should at least have access to a UX person if they don't have one 100%.

[00:14:11] We try also to give each team, or several tightly coupled teams, one opportunity or problem area that they will solve. So the new positions, for example, we have some teams tackling how to make invoicing and billing[?] extremely easy for people. So they get this objective and then they're responsible for finding the solution and also the results that this solution brings.

[00:14:46] And then also, within our product development process[?], we have three principles that really guide these empowered teams. One is that we tackle the risk as early as possible, before we actually start building and also while we create the products. The second one is that we define the products together. And the third is that we try to focus on the results, not how much we ship[?], not what we made, but really how did it affect the objectives.

[00:15:18] This is very easy to say, but it's quite hard to do every day and in the communication, because in general if you have a lot to do you get stressed, and everyone has a lot of opinions on the way things look and not as much on this. So this is the constant emphasis, trying to get us to focus on the objective and the results.

Discovery, delivery and an accessibility example

[00:16:01] With these teams, what we try to do is to really make sure that across the organization we have a cross-functional team joining both in the beginning, when we're kind of more at the opportunity stage, as well as when we are actually creating the products. So we have this loop that we work on. Of course it's not as clean as this, it's probably many, many loops together, but we split it into discovery and delivery.

[00:16:36] We have kind of the first step where we're setting the goals. We have an insight phase where we do a lot of analysis, qualitative and quantitative[?], figuring out is this an opportunity worth going for. Then we move more into an exploratory phase where we create prototypes, we do user testing, confirming that this is actually a problem that we have identified. And then, before we think we really have something that works, we start building the product, and then we work together to actually launch it into the market, and then check the results and do it all over again.

[00:17:11] I'll give you one example of where we're using one of our product principles, of being accessible, so that even if you're young, if you're disabled, you should be able to use us. This is also an example of how we tackle these risks very early. Being a company of quite a size — we have 3.4 million users — we really need to adhere to all the disability standards.

[00:17:40] Here we have Christopher, who is blind, and[?] this woman is[?] seeing actually how does it feel to use it. But not just that, this was extremely effective, because they can really see and listen to how he uses it. We always use VoiceOver for ourselves as well, but it's very different in reality. This woman really struggled to create an account, and we watched this[?] to really understand how it should work.

[00:18:16] I have to say, after we did this one-hour session, of course everyone ran back to their desks and really did their best to fix it. And I have to say that about a month, a couple of weeks ago, because this was one of the worst apps[?] with VoiceOver, so blind people could not use it, and with the effort we've done this year, we really were embarrassed[?] and kind of fixed it, and the result is that[?] without us asking or doing anything, now it's almost like a commercial. So that's the two things I wanted to say: the roadmaps and[?] closer.