Panelists
Jane Austin Director of Design & UX, MOO
Janna Bastow Co-founder & CEO, ProdPad
Leo Nilsson Chief Product Officer, iZettle
← All talks
Product Turing Fest 2017
Panel Discussion: Jane Austin, Janna Bastow & Leo Nilsson
Jane Austin , Janna Bastow , Leo Nilsson
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Jane Austen: name is Jane Austen, I'm Director of Design and UX at Moo dot com, which is a pretty awesome company. It's basically disrupting the print market. You can go in there and print yourself lots of different things, but we predominantly do business cards.
Leo. My name is Leo Nielsen. I'm heading product management at Isobel. I've been there for roughly four years. Isobel started as a mobile payments company, but has sort of expanded its portfolio to include both software and hardware products to manage sales for small businesses.
Hi there, I'm Jana Bastow. I'm co founder of Prodpad, which is product management software and co founder of Mind the Product, which is a community for product managers. Cool. Thanks. So my first question, I presume when you wanted to grow up, you didn't want to be a product manager.
I know you're not a product manager, but how did you get how did you get into it? What got you interested in it? What was your route to get there? What what do you like about it? Yeah. Mean, I've got a good story about how I got into it.
I had no idea what product management was when I actually accepted the job for it. I was a customer support rep at a tech company, and I was kinda taking on the role of product management, you know, communicating with the dev team and whatnot.
And my boss pulls me aside and says, I like the way you call ******** when you see it. So I kinda stay off. Your mic is flipped. Oh. None of you guys heard that, did you? Delicately done. All good? Do we just need this up here?
How about I just hold this here? Is this alright? Can I give you a hand mic? Yeah. I mean, I kinda got one now. So, yeah, sorry. I was a customer support rep. I was pulled aside. Testing. Nope. Oh, there we are. Alright.
Wait for the echo. Okay. Good. And so I was pulled aside. He, wanted to make me a junior product manager. And I was like, great. What is it? Ended up taking the role. I had no idea what I getting myself into. Went to my desk, Googled product management, and there's just nothing there.
This was about ten years ago now. I know the situation changed now, but back then, like I'd gone through business school, I'd never heard of the role of product manager. All of a sudden I found out I was one. So that's been a fun journey.
Brilliant. Leo? Yeah, I think from my end when I joined ICESat-eleven, which was in mid-twenty thirteen, at that point we really didn't have like a big product function or product management function at the company. So when I joined was really about we had this one product which was car payments for small businesses and we were about all about scaling that into new markets.
And that's kind of how I got into it at ISACO to sort of focus on sort of scaling that product into various markets which include all of these launch cycles and sinking every stakeholder in the company. And I think what because your question was also about what you dream about, and maybe I didn't dream about becoming a product manager, but what I like about it, or what I liked about it at the time I think is that and I think everybody who likes product management or perhaps
design and engineering essentially likes problem solving. And I think there's an interesting layer to problem solving in product management, which is this additional layer of actually defining the problem and then also trying to solve it. Whereas a product manager also should be a bit hands off, of course, when you solve certain product problems.
I think that's kind of what got me stuck into it and really liking that work. But it kind of grew organically within isatl dysfunction. To you. Alright. I think I dreamed to be the fighter pilot or a vet when I was little and I don't know, I just drifted into UX.
I've got a Masters in Philosophy, and my dad said to me, Oh hen, there's no adverts for philosophers doing the job centre, what are you going to do? So I did another degree, ended up doing, it was in hypermedia, that's how long ago it was, and then suddenly I invented almost a job of making things easier and thinking about them, which is what I love.
Did my first degree, was just thinking about problems, and yeah, sort of lucked my way into this job. Brilliant. I mean, don't know how many people in the room are part of have the role exactly of product manager, but I guess one of the things maybe a lot of companies in here are in that process of just starting to form product teams.
I know like we've gone through the process of float recently where we had a you know, it was just me and a co founder originally and we were problem solving every day and it was great and it was very hands on. And now we're a company of fifteen people.
We're kind of in that we've got to put processes in place, it starts you go through these different seasons of, oh, it's painful and doesn't feel quite right, and how can we use processes to fix this and make it better. Have you guys in your journey find any times where you've hit the wall a bit with product, things aren't working quite right?
And what did you do to what have you found what's worked to make it better at different phases of growth? Well, mean, for our team, we're a micro team. We've got nine people total in the company right now. And at the time, it was founded by myself and my co founder, both of which were product managers.
Neither one of us actually had official background doing anything else too much. Right? So we were building this thing. And we actually ran into a block because we realized that it was two product managers. Neither one had official ownership and then two developers.
That was sort of the early core team. And it meant that we were running into blocks around things like, you know, there was no one who actually owned the piece of going out to the customers and testing out the designs and everything else.
And the rest of the business kinda got in the way, you know, everything else was trying to manage things. The one thing that we made that made a big difference to the team was actually introducing a UX team. So a UX designer and a UX developer to actually round out that product piece so that we could actually get things done, create prototypes that we test with customers, design them up, make sure that everything's good and ready, and then send on to development.
Great. Yeah, I guess I can kind of resound that in a sense. I think, you know, it's quite easy to say that you or maybe easier to say that you need a certain type of resources to be able to scale things. Maybe you don't have those resources.
But if you can get the competencies of UX design, put that together with developers, as well as a sort of if you can get a seasoned product person, that would also help you. But just because I think the key to success here is really to get the methodologies into place and also learn quickly how to sort of fail fast, test easily and simply and really scale testing hypotheses.
Now there are many, many methodologies to use here, but I think it comes down to sort of, you know, learning as cheap as possible, especially if you're bootstrapped. So if you can get the core competencies in the same room and make them work together towards the same target, like if they have the exact same idea where they need to go, that will take you know, take you miles.
My story is quite different. I tend to specialise in digital transformation, so big organisations like Citibank, GDS, Government Digital Service, The Telegraph and MOO are all organisations which already exist and they are trying to put good, agile practices in place. One of the things that we've discovered for this to happen is you have to remove interfering, meddling hippos you know hippos?
The highest paid person in the organisation. If you can somehow get them out of the picture and actually allow the teams to get their own car done and to start shipping stuff and to bake research into it quite early, that for me is the big win.
Then after that it's just calling out assumptions. Are so many businesses operating these massive assumptions and if you can just make people aware of them and then try to negate them, that's another big win. Brilliant. Have you got any examples of that in MOU in terms of assumptions that you didn't realise you were making that came to light and it was like, oh that's Well the one, probably boring for people here, but the very lovely MOO businesses Services, that's the B2B branch of Moo, and their sales and marketing team felt that they needed to
have a tool for their bigger businesses to be able to approve their purchase and use of print. So it was great getting the sales and marketing guys involved, and we had this really nicely designed piece, and then we realised our biggest assumption was that all businesses operate the same, and the ones that we talked to might just be a small subset of all businesses, so actually unpacking that and realising that this thing that worked for these people didn't work for everyone was one of our big wins, and showing that
iterative research and unpacking assumptions really saved us a lot of money and prevented us going down this completely wrong route. Brilliant. To that same question, I think, you know, I would say that perhaps the entire sort of development that our product has taken was based on sort of discovering an assumption.
And I think at the very start, ICESat launched as an idea of helping the payments because people wanted payments and they wanted to accept car payments without necessarily thinking so much about why they wanted car payments, right? And the assumption that came to light after a while was and I mentioned this in my talk earlier was that, you know, payment is really about making that sale.
It's not it has nothing to do with security or convenience of getting the money paid out quickly or whatever. It's really about that if you don't accept car payments, your customer may turn at the door and go next door. And that was sort of an assumption we discovered basically by just talking to customers and sort of reevaluating our view on how we were actually helping them.
So we kind of constantly try to do this. And I mentioned another thing, I'll mention it again. Think it's a method called impact mapping, which I find really, really helpful in sort of mapping assumptions. And you can do it on a company vision level all the way down to like a user story level.
What's the assumption underlying sort of your conclusions? Just to drill into the iZettle challenge a bit, I was recently in Berlin where nobody seemed to take car payments. How do you that's a problem. Is that a product problem? Or is it a market problem that's just the market doesn't want it?
A macroeconomic number you can look at, is amount of card payments per capita per year. That number in the UK is roughly two hundred. It's two fifty in Sweden. It's sixty in Germany. So you have a different market. But the truth of the matter is still that Germany has other issues.
They still need to manage their sales, to send proper receipts, to manage inventory, to manage their customer data. Now in Germany there's also come a new cash register law. They need to store all of their sales data for ten years in a compliant system.
So that's what we build. So again, when we expand our focus to managing sales rather than focusing on payments, there's a completely new opportunity opening up in every single market we're in. Brilliant. Jean, you talked about the hippo getting out of the way.
I mean, of the things I know that I've been finding recently is as the company grows That you're the hippo? Yeah, how do I get out of the way? That can be difficult to let go of, you experienced that and how does that work for where you are at the moment?
Probably the only way I can map your is for me building a team. When I first moved up into management I used to agonise because I realised I wasn't designing anything and I thought oh my god I'm so lazy, I'm not actually doing any work', and it took me quite a while to realise that what my work was was something completely different and it was about setting that vision and making sure that people had the space to operate in and they were protected and they knew where
they were going, and that I set the processes, but actually the team then came with extra brilliant processes, so getting at people's way makes the whole team operate better. It took me quite a while to learn and I still feel sometimes that I'm actually not doing any work.
I think it's a kind of mind shift. Kelly? Yeah. Mean, really similar situation. The company was founded by two product managers, and we had to hire somebody to help us actually lead a lot of the efforts around deciding what was going to go into the product.
At the end of the day, it comes down to what the customers thought of wireframes and everything we put out there. So handing that over was one of the toughest things I've ever had to do. But the reality is is that, you know, the entire company becomes more effective.
We're hiring people who are actually better at this than I ever was at design or anything like that. And it makes a big difference. And I do have be careful not to be the boss who sends crazy ideas. I'm at this conference and I picked up this thing and drop it into Slack and hope somebody picks up on it.
I don't wanna be that hippo who throws things in there as a grenade and explodes the plants. So I was very conscious about how I put things in there, suggestions, and go, well, actually, this still needs to be aired with the rest of the team, this isn't just me saying we need to go do this'.
That was a great point you made about hiring people better than you. I try to do that all the time, it's quite humbling when you hire these people and they're just so incredibly awesome. If you don't hire people better than you, the company won't get better.
So your job really is to find those great people and inspire them, rather than telling them what to do. Well it's interesting because I am listening to audiobook, Steve Jobs' autobiography at the moment, and it's amazing how involved he was in so much the product, but yet, you know, as a culture that doesn't feel like a very good you know, it doesn't feel like something I want to personally aspire to.
So it's that challenge of knowing where to, you know, where but what the product they were able to build was actually able they were able to design something beautiful all the way down to the packaging. I don't know if you've got any thoughts about it.
Well, I will say I think Apple interfaces are really crap. Know iTunes is really crap. I have such a nightmare trying to use it, so that might work for physical product design. Personally, would somebody would actually sort out iTunes, so I knew what was going on, so I will leave you with that thought.
I would agree. Sorry if there's anyone from Apple in the room. Have you found you've had to step out of the way as the company's got bigger feel bigger? No, actually I think it was mentioned in our previous talk today that the job completely changed.
You start as a product manager and work with that for quite some time, but now my work is basically enablement of others in my mind. It's about enabling to make sure that the teams are fully stacked, they have the competencies that they need, that they have the connections around the companies that they need, that new people are onboarded properly, finding new talent.
Like that's what I go and worry about. And making sure that we have a very clear vision that people everybody needs to know it and so let's try and evangelize that as much as I can. And that's really to help the discussions that the teams are having amongst themselves.
Again, trying, you know, at some point people might leave something up to you to sort of get your view, but I try to sort of stay away as much as I can in that sense. Yeah, absolutely. And one of the talks, don't know if you were in a session that Rosemary just did about creating a culture of, you know, that it works to kind of throw out ideas and try and experiment.
I mean, you find times whenever the culture is working for you and when it's working against you? And have you had to bring any changes in there to say, look, we need to change things up here because we're not getting as much experimentation as we want or as much playfulness in the team?
Does that resonate? I'll have to admit, I wasn't in the space talk. Was on a call with Moose. I'm really disappointed I missed it. I think probably the only time that has happened is when we have got, I wouldn't mention particularly the previous job, but when the product and design team, we were being really experimental, we were failing fast, were doing really well, we were starting to get a lot of traction, and suddenly some very senior people were like, oh, that looks really good, I'll have a bit of that,
and our team was broken apart. Sometimes, actually, when you're doing a transformation, that's the point where you become so successful, the culture absorbs you rather than learning from how it makes things work, it absorbs you and puts you into the structures that they already have in place, and that didn't work.
That's a very dangerous thing with a digital transformation. That's what my bad experience is, it stopped being fun, because suddenly you had all these structures and processes and BA's which we hadn't previously had, and we had to fit into this existing process. So, yeah, that's a warning for anyone doing a digital transformation.
I think one thing that did have come up for us when we sort of tried to scale these different methodologies and in a sense trying to take what we can do for one team in terms of discovery and delivery and scale it to sort of include the entire organization in various levels.
A tricky part with that has been to maintain a culture of innovation. Because it's very goal driven. It's very driven on sort of setting a clear goal that everybody agreed on. And I think the trick here is to on how you set that goal.
Because if it becomes too specific, you kind of limit where you can take the product. So I think we have and to some extent are still battling that a bit. That's kind what we're working on now to make sure that and then we have things hack weeks and all that.
But when you have a hack week, you see all these great ideas, but how do you actually get that great idea into development? If it's you know, then perhaps if it's completely outside the vision, maybe it shouldn't be in development, but there are some that are.
So that's one of the sort of trickier parts that we're currently working on, I think. Yeah, yeah. How often do you have pack weeks? It's changing, believe. It's once a quarter, I think. Yeah. Tell the team. Yeah. We we started doing pack weeks last year because we'd hired a couple extra people and, you know, we had the people on the team.
We kinda thought we'd have more stuff happening, but at the same time, it wasn't quite gelling. We're a partially remote team, so we decided to bring everybody together and do our first proper pack week. And we basically just removed stuff from the roadmap, just made room to say, let's just spend some time figuring out what can build here.
Turns out it actually could turn into something that fit within our roadmap and we actually launched out there. But the goal of it, I basically told the team, was like, we are not going to launch this. This is something that we're just going to practice working together and just see what comes out of it.
And at a great time, they built something and actually put a couple extra weeks into it, we did launch it, which was great. The other thing we implemented was, I call them powwows. It's a name that kinda just stuck. I don't know why.
But Friday afternoons, we have a little update round robin type thing, as well as have one person on the team just show off something interesting that they're working on. It could be work related. It could be completely unwork related. And there's always something interesting happening.
It's fun to kind of show off the different skills that people in the team have. Brilliant. Actually, in saying that, MOO is a very playful culture, have loads of great communications, we have demos, we have lots of events. So yeah, you're right, and I think that's why we're gelling as a team, because there's so much of this playful opportunity and we do really good tackling as well.
So yeah, I'll have to check out Rosemary's talk, I'm so sorry for missing And do you think that playful culture is in tension with really pushing, driving goals and trying to hit targets, does it come into I think there's a bit of that, but I think also if you are going to be working in a fairly autonomous agile team, people have to trust each other, enjoy each other's company.
I will say that I try to hire people that I'm pleased to see in the morning, so people have to be pleased to see each other in the morning, and one way to do that is to have this almost non goal driven, really nice experiences together, some of which result in products, but mostly it just results in trust and good working relationships, which are so important if you're working in Agile.
Yeah, brilliant. And I can't remember who was talking about, was it you who were talking about OKRs, KPIs? I mean, could you guys talk about how you've implemented those kind of procedures in in the organization? Yeah. Mean, I guess one of the reasons why I don't really care whether you call them OKRs or KPIs is that we've actually found something that works for us that's, I don't know, maybe in between, our our own style of doing it.
Basically, what works for us is picking a single objective per roughly per quarter. We kinda switch it up every few months, and just try to think of things we can do to go do that. So last year during Fest, I spoke about what happened when we focused just on onboarding, trial to paid conversion rates.
Right now, we're just thinking about how do we get more people to use more of our features more often, so engagement. And I mean, maybe I'll report back in a year's time as to what came out of that, but we just focus on one objective at a time, partially because we don't have enough people to focus on multiple objectives at the same time.
Brilliant. That's good. Yeah, I think our way of doing something similar is something I also talked about, which is a company that's, which it kind of is a type of OKR because what's really important about them is that it's a company wide sort of strategic initiative but they're, you know, they're closely attached to actual target that we want to hit.
And actually we don't consider that to be done until that target has been hit. It's not about shipping a product or doing this or that. It's about hitting a certain target. Now we're so big at this point, we will have several going at the same time.
But we have sort of a work in progress limits. It basically works as any type of backlog. That's kind of our way to aligning around sort of bigger objectives. But then you also more on that sort of closer to a team level, that's kind of where you have this KPI.
So they will sort of set goals for know, that kind of differs, be honest. We let them handle that themselves if it's quarterly or semi annually. It doesn't really matter. Okay. Basically what he said is pretty much we're on the road to that, we're still getting there, but one of the biggest things is limiting work in progress and having a company roadmap and saying no.
That's really important. The only thing I'd add to what Leo said is that being able to say no, is it on the roadmap, is that a bet? Nope, sorry, it's a great idea, and actually quite a good hippo wrangling tool you could use.
Yes, yes, yes, Okay, well, we've got about eight minutes left. I wanted to open it up to the audience. So I'm just going to grab that other microphone that's up here. Does anybody have any questions from the audience? Are you able to sit around?
Hi, Hillary from Skyscanner. One of the things we struggle with is when you have a strong PM team or PM function, a lot of the rest of the business feels like they don't have so much say in what gets done because they see the PMs as the only people who could make that decision.
They own the road map. How do you guys think about that in your organization and making sure you continue to get the best ideas from the whole company, not just your PMs? I think I touched a bit. We definitely have encountered such accusations, I would say, towards our product organization.
But I think they actually stem from other problems, generally. I think the main issues that we have are ideas or requests that come in and they basically are based on misalignment on who it is we're actually targeting. So we can have when you don't have a common understanding of who you're trying to serve, like who is your customer, you can easily get into that trap where a product manager has one view and salesperson is trying to close another type of customer.
For us, I think and I did talk a bit about this we are trying to establish what we call sort of value proposition streams. The idea there is to kind of extend this cross cross functionality of the product team across other functions in the business.
Because actually the entire customer experience is not dependent on exactly only what you produce. It's also about what support they get, how they're met by a salesperson or through the marketing, what's the messaging. And basically everybody in that sort of value stream or in what we call a value proposition stream should be thinking about the same overarching KPI.
And then just be very aware of how their own teams contribute to that particular goal. And this is also a where I think this is a forum where they should be questioning each other. Is this really the best sales tactic? Are you trying to target a bigger client than you should?
Is this really the right segment? Or actually generally sales in our business, they are the ones that meet customers on a daily basis, more than many of the product managers actually, right? So they have really valuable feedback that you need to consider. But it's hard to consider sort of each other's work if you don't have a very clear idea of what goal you're working against together.
I guess I could add to that. We make sure that everybody in the company is aware of who the customers are and what their issues are. We tie it back to, you know, does it align with our vision? Does it make product managers better at their job?
If yes, then go. Does it match with our objective right now, which is getting more engagement? And is it useful for the type of people that we're seeing come in through our so we have a feed in our in our Slack channel. All the feedback that we get in from customers comes in there.
And then we have discussions around it going, well, why would somebody ask for that? And everybody jumps into the discussion going, oh, I can see the reasoning or I can see what you know, whatever else or let's ask him or whatever else, but just making sure everyone can see those conversations with the customer and understand what it is that we're trying to achieve in the long run.
I'll just add to that, I agree with everything you've said, we try to make research a team sport, so everyone has access to the research, we do the research in the open, we try to make sure, this is an ongoing problem, how does one have these living personas, to build a product to fix that one, but we try to make sure that people understand who the customers are, we also include sales and marketing, so our kick offs we do big sketching exercises with them and we try to understand what customers they want to target
and what aspects of the product would help them target better. We only have a small sales and marketing function, we also spend a lot of time just trying to understand who our broad customers are using segmentation and data. Once you assemble all of this, it really helps you focus on what you should do.
But it's not easy. No, that's a good answer. Is there another question up there? Down at the front. Hi. This is a badly thought through question, so please forgive me. So I come from a background of operations and infrastructure. And I really value guys, you, your opinions on where operational stuff fits into product ownership and product management.
Do you mean sort of internal operations at the company or? No, no, mean keeping things live and making them responsive and site reliability. Oh that's different, thought you meant operations as in getting the product out of the factory into the customer's hands? Oh no, sorry, I meant keeping websites alive.
Isn't that part of a DevOps platform or a platform which would have its own product manager and treat it as a product? I think it could be, but I also think that keeping your part of the product live is the responsibility of the product team itself, including the product manager.
If your product doesn't work, you have a problem. You can't deliver on your targets if the user can't use it. For us, think this is very deeply rooted in our DNA because if payments go down during lunchtime, you will hear about it. And if you have a small business, by the way, as a customer, they won't turn directly to you, they will turn to social media.
So it's really important that things are up and running. But I think it's very important that it's part of the team's responsibility as well, that they don't just give this to some other team that they're responsible for uptime. That's quite dangerous, I think.
I've seen with BEST as a merged responsibility, you're responsible for your part of the site, you have an underlying platform operation team who are responsible for things like APIs, and they again have a quad, they have the same agile function, and they also care about the customer as well, they are connected to the crews and have a product manager responsible also.
So that's how I've seen it work best, that kind of matrix model. If a company cares about having uptime and being responsive and being something that people can actually use, which they should, then it should be part of their actual KPIs. It should be one of their objectives.
When we went and rebuilt our entire platform, platform, the objective was make this thing stable and make it fast. Don't do any new features, don't do anything like that. Just put all of our effort into finding ways to make this happen. And it paid off in the end. It made a massive difference.
But I mean, with something like the API, we treat that as a product in itself. It's got its own roadmap, it's got its own set of users, some of which are internal. Exactly, and we do user research with our internal users who will be using the API, so we actually treat it exactly like the other products.
I'll admit, we don't do user research on our API product if it got that far. We're about to kick off some about how our internal team are using it, which is fantastic, internal ethnography. I'm going to get to look at developers all day.
Yeah, and from our end, would just say that speed and reliability need to go on the product roadmap. So if it's not at a good enough level, that needs to be fixed as top priority, and we've been there. Thank you very much. Probably time for one quick one.
Real quick one. Yeah. I was wondering if you guys could share, like, the sweet spot for, like, a team as a product manager. How many people you could be working with at one point as a product manager? What areas those people would be in?
Have you heard that it was at the pizza, as many people as it takes to could be fed by two pizzas? I agree with that room actually, I think it holds. We've got a team of nine and I think we've got our real sweet spot there, eight of the people are focused primarily on the product side and it is a really nice side nice size to be able to get things done.
The big thing that made a difference was we we hired a UX designer at first, which was great, but then we had somebody creating designs way faster than we could actually integrate them because the front end developer was doing everything from, you know, managing the angular back end to make sure this thing still went fast through to, you know, trying to help us do CSS animations to make it whiz pop just the right way.
And of course, what got left out? Well, anything that happened in the proper, you know, like the visible front end, the UI stuff. So we hired a UX developer, somebody to work on the UX team, but who was a developer, who originally was hired just to do HTML, CSS, jQuery prototypes just to test things out.
So we have a product manager, UX designer or two who's responsible for UI and research as well, tech lead, an agile coach, then we have these persons responsible for the testing delivery, and then we have full stack engineers, and then they all work as a unit and observe some of the research together and often collaborate on what the solutions to the problems they're seeing, but it's led by that quad who are the people who make the decisions we call that consent not consensus, so that means not everybody has to be in every meeting,
but they're all aligned around the same problem, the same KPI, the same OKR. And that's us. I really want to ask what an agile coach does, but I think we've sadly run out of time. So can we thank the panelists, Yana and Neil.
Neil and Jane.