“The only failure is to fail to learn.” Paul Aston

Paul Aston is the Product Owner of Volvo’s Open Innovation Platform and a Lead Technical Designer at Volvo Cars in Sweden. He is passionate about finding new ways of using tech with a strong connection to digital.

Creative technology, teamwork, and lessons from user experience-driven pilots are the most important elements for him when exploring new horizons. From his vast experience, both as a developer and a service designer, Paul confirms the importance of a customer-centric approach and brings in-depth technical knowledge to user-centered design thinking.

You can connect with Paul on LinkedIn and you can check Volvo's Open Innovation Platform.

Listen to this episode on Apple Podcasts, Overcast, Spotify.

Please enjoy:

Podcast transcript:

Attila Tóth: Hi Paul, welcome to the show. Before we dive deep into the topics, let's start with a bit of history. You had a fair share of working in both development and user experience design. What was your road to becoming a product owner?

Paul Aston: Hi, yeah, thanks for having me for a start. Yes, the history I suppose it's a long and varied one. I mentioned the other day, one of the problems with getting older is your short history seems to get longer and longer. But yeah, my path to becoming a product owner, especially in sort of a service-designed space, it started actually when I still lived in the UK. I was working for a company producing audio and multimedia guides for museums, and that was kind of the thing that really kicked off my interest in digital interpretation, and in creating ways of communicating with users and developing new user experiences, especially when we were in that transition phase from going from pure audio to what we could do with touch screen since the advent of the digital handheld. From there, it was a shock, a big move that I moved to Sweden, and married to a Swede, and it seems to happen to us all eventually. Since I moved here it was kind of a chance to start fresh, so I set up my own consultancy producing apps, we did some interesting things working with offshore powerboat racing, and some things like that. From there, I started to build a reputation as a frontend developer, so I got into some really fun creative space, doing a lot of corporate sites for architects and photographers. From that, it was very much the Gothenburg tradition. I founded a startup with a partner, worked on that for about three years, and as is the way of about 90% of startups, it failed. But the good thing with doing that is you learn an enormous amount, so off the back of that, I was offered a job working for a very cool little digital service design agency in Gothenburg, a place called Humblebee, and when we were there, my main role was to start working on this embryonic innovation team in Volvo. They decided to reach out and find external collaborators to try and get that outside-in perspective. So it started off, I think it was six of us in a small meeting room, and it was hot and stuffy and we had no windows, and it got very fraught and angry. And then we grew that to a team of around 30 people, and the way that we worked there is… Our work was based around design thinking, so it was very much notate insight and input, generate a hypothesis, and test it and validate it. And with that work, you tend to sort of have, you know, some of the leading of particular projects. We got a very flat management structure in the team, but there would always be a kind of a project lead who’d, you know, either it was their baby and they were ushering it through, or, you know, they were the right person to see it through. And so one of the concepts that came up was looking around creating a sort of digital innovation platform. We liked the idea of like, you know, a classic developer board to make our APIs and digital tools accessible, but then how can we use that to accelerate innovation within a company. So that became my project, and I started to validate it. And the best way to validate something, that is to stop running some small experiments, start putting things out, small tests just to make sure that our fundamentals were correct. We always talk about knowing the fundamental unknown. And if you could answer, you know, that question, then, you know, you're on to win it. So I started driving that on with the innovation portal, and it snowballed from there. You get to a point where the project clearly was going to work, we had really strong internal stakeholders but for them to be able to kind of pin their flag to it and say yes, we support this, that project needs a product owner. And that became me. I kind of fell in love with the project, it's been my baby now for a year, and so I decided I’ll run it, I'm pretty much running it anyway, I'm going to take full ownership of this. And that's how it came to me. So now I’m the product owner on the innovation portal.

Attila Tóth: Wow. It's a really nice career path. So you basically started from scratch, you touch based on design, frontend development and worked on the ladder, and I really love how you put it that the startup failure was actually a learning, because I think many people think of digital as straightforward to success, and surely it's not that, so I'm glad you put this on the table.

Paul Aston: I fully agree. I think one of the biggest... One of the phrases we always have is “The only failure is the failure to learn.”, especially with digital. If you're creating a new digital service, it will never be perfect the first time out. Very often, you know, it'll be completely wrong the first time out, so you have to have these failures because it's a great learning. And it’s not even necessarily a failure. It’s “We tried something, we understand the audience does not like this, but we were clever with the way that we tried it, and we do understand what it is they would like instead.” And then, you can pivot, you can change. But you're right, I think people are always scared of that failure, especially in a corporate environment, because then it's very much there is no plan B. We all know that plan A has to work, whereas half the time, with the way that me and my team like to work, we’re down in plan H, J, K.

Attila Tóth: Right, right. I think many corporations are still lacking these dedicated product owners in their teams. This is a sensitive question and I want to pick your brain on the topic. What do you think the reason is behind? What was your experience with Volvo, and, as you said, with other projects, and maybe through the consultancy you had? How did you face this challenge where there was no dedicated product owner?

Paul Aston: Yeah, I mean it amazes me when there isn't one. It seems like the most logical thing to have. When you don't have that in place, I think the only way to really deal with it is you have to build a stakeholder. There is, there will be someone to whom that project is key and is important, and that person should also be a subject matter expert in that project. Well, in that product. So if you’re working on the outside, you know, coming to a company who wants, who have a desire for some kind of product or service, but they have no dedicated product owner, you need to find the person that, I think, has the most to gain, or has the most interest, or the most engagement, and almost build them into that role, make them that person. Otherwise, there is no single point of truth, and what will happen is you then end up with the classic too many chefs, where you get multiple inputs from multiple different teams with multiple different values and outcomes, and you just lose your focus. You have to have that clear side of understanding exactly what it is that you need and that one person to direct that for you.

Attila Tóth: Yeah, I think it's very important what you said, that if there are too many inputs, you lose focus and you lose direction. So very good points here. Now in our audience, we have a lot of business people who might not know what the product owner’s job is. How would you define the role and responsibilities of a product owner?

Paul Aston: That's a good one. I think it... I mean, you can say it will vary according to the products, but I think there are some core things you have to do. One, you have to be the evangelist of the product. You have to be the person in your company spreading the good word, you have to be out there, saying: “We are building this thing. It's gonna be amazing. There are benefits to it. Here are the clear benefits, here is the value.” So then you have a very clear communication across your entire company of what it is this product is, and hopefully, you know, generate some excitement. When a company's building something new, people should be excited you're building a product, that’s what you’re there for, so that's kind of your top level. Underneath that, you then have to be – I think I mentioned it in my earlier answer – the single point of truth. So anyone can come to you, and it could be somebody who's in the development team, it could be someone from an external consultancy, it could be someone from senior management coming down, and they have a question. And you should... they come to you, and you have the complete understanding and you can give the clear answer. Because the other part of what you're doing is you're the one that should be defining the strategy for this. And that's a tricky one because you have the strategy for your product, you have to make sure that fits in with your overall corporate strategy, you need to be able to argue why that makes sense, and so you’re driving that product on. And then, that's in a way – I often use the analogy of the swan –, so that's kind of the surface level of it, that’s where you’re calm, you’re collected, you're there showing the public face of your product. Then, underneath the water, you’ve got the legs frantically pedalling, because then you’ve got a team working with you on building this project, so then you become kind of the ringmaster of the circus. You have to coordinate your different development teams, you have to coordinate with UX, you have to coordinate with marks, you need to make sure that everything is aligned. You need to make sure that your development plan is going the right way, and you also need to be making sure that you're testing and improving your assumptions because if you base what you're working on a large assumption, tested early on to make sure that you're right, will be prepared to pivot. So I mean it's quite... there's a lot to do but the main thing is just to be that person who believes in the project and the product, who understands the strategy, is able to communicate it clearly and then is also able to facilitate a team to deliver the product without interference.

Attila Tóth: Wow, it's a handful! So if I want to sum it up in the business language, one of the main important things is that you have to be a leader who takes responsibility for all of the outcomes. And this means you're the single point of truth, this means you are the one who has the arguments why this product is important for the corporation, and basically you’re the guy who is trying to answer all the questions, and even if you cannot answer, you know the way, you know the road you choose, and you know what's the direction you are going forward with.

Paul Aston: Exactly.

Attila Tóth: Cool. I'm just putting this on the table because with COVID-19, we had... we are a digital transformation agency, and we had a lot of questions coming in:  “Okay, how do we create in this pandemic an innovation that can facilitate growth?” And I think the role of a product owner is really important in digital growth, but I would like to see your opinion. How do you see the connection of being a product owner with growth, especially digital growth?

Paul Aston: Well, I think going back to what we spoke about earlier, it’s... I think all of it comes down to understanding of strategy. It's what drives a company onward, I mean it can depend on the size of the company. Sometimes, you have a small company who have one very clear goal to increase customers by a 150%. When you get to sort of a large corporation, you have a problem of various translation layers between what is communicated as the strategy and then what other leaders in the company… how they interpret the strategy. So as a product owner, what you need to do is understand what other leaders are thinking and how they are interpreting the strategy that is laid out, how your product fits into that, and then be able to work with them to make sure that you’re not… you shouldn't ever be sort of stepping on somebody’s toes, you shouldn’t be getting in each other's ways. You should be able to work together to see: “Well, if you’re doing X, I’m doing Y, how can we create a mutually beneficial outcome to this?” And especially around digital growth, I mean, that's where it's super key that everyone works together. Because everything that you’re working on should be complementary to your overall ambitions. So I think, as a project owner, or a product owner – sorry,  then yeah, it's basically to make sure that you’re there to, again, you’re there to facilitate, you’re not there to block.

Attila Tóth: Mm-hmm. I really like that idea to work with other people, to not step on their toes and to help them achieve their part of the strategy, because many times what we see is that, especially with corporations, there a lot of departments and a lot of other leaders who – as you said – interpret in different ways the strategy, and many times product owners have difficulties to fit into somebody’s strategy. So I'm really glad you put it on the table that your role is to find a way in the strategy that helps other people. So the product should be a facilitator of growth and not something that blocks it.

Paul Aston: Exactly.

Attila Tóth: And as we are talking about growth, I think there are two points: one of the points is success and the other point is failure. How would you define it in perspective of being a product owner?

Paul Aston: Hmm, I mean, success is very often difficult to quantify. I mean, we all dream of, you know... The classic success is I release, let's say, a digital product and within a week, I have ten thousand users. That's what we all aim for, we want to see our users take to our product and use it, and be engaged with it. That's kind of the classic success formula.

Attila Tóth: That’s the dream.

Paul Aston: Oh, it is. But I think what you have to do is look at how your clock tick, look at how long this could take because whilst digital development can be very quick, sometimes the path to the product is very long, so I try and sort of celebrate small successes along the way, all the time. You know, it could be something as simple as we send out a user survey, and it would appear that 70% of the respondents like our product. Great! We tested and we validated the hypothesis. That is a huge success. The dev[eloper] team have conquered a particular technical milestone. That is a success. Sometimes, it can just be, you know what, that we’ve had a cold review and we have successfully defended the product. That's a huge success. And then, once you get, you know, to celebrate all these small successes, that keeps you going. That kind of gives you the energy you need to keep pushing for the finish line, because the problem you have is, you hit that finish line and you launch, and then you have the big success, the dream success of many users are engaging. Your job isn’t over then. Your job is now: “Well, I've got ten thousand users. How do I increase that to twenty thousands? I have feedback, I know I need to pivot, I need to change this, I have my development roadmap in front of me and we have twelve more development cycles to plan.” So you're never going to cross that finish line, there's never gonna be a point where you sit down, press your hands together, and note: “That's good. I'm done. That’s a success.” So I think it's a case of celebrating all successes in whatever order of magnitude. Definitely, launch days and good user numbers are days for champagne. The rest of the time, you know, it’s raise a cup of tea and say cheers to the office. But for failure, as I said, the way I see it, the only real failure is the failure to learn. So, if I launch and I get ten users, okay, that’s disappointing, but my failure would be then to not know why I only have ten users. But if I can create my launch in a way where there’s some kind of A/B testing or some way of being able to test the metric, or it’s a fact I have launched having made a decision between an A and a B, and it didn’t work, then if I can understand why it didn’t work, and have an alternative and then be up to move on and then test that, and then refine the hypothesis, it's not a failure per say, it's just a very good learning opportunity. And having these moments are great learning moments because if everyone just likes it and you don't get any feedback, it could be hard to improve. If you launch and there’s a feature that everyone hates, then you know very quickly that well, this is cleaning up something that’s going to work and you can feed that back into your development cycle. So, yeah, really, failure is when you just throw something out, it doesn't work, and you sit back and kind of scratch your head and go: “Well, it must be the people who are wrong.”

Attila Tóth: Yeah. And I just want to dive deeper a bit on this, because I see many times happening that a corporation decides to have a digital project and I will tell you two scenarios, and let me know if you can agree on that. So one scenario is that, as you said, they fail in the first week of the release, and then they stop: “Okay, it’s the people, it’s the market, and it's not for us, digital is not for us. So that's option A. Option B is that they have a success, like let's say they have ten thousand users within the first six weeks, but then something changes and they stop growing, and they cannot explain it because they didn't have any previous tests, any failures, and they are just blocked, and they are again blaming the market or blaming the people. So I think it's really important to think of failure, as you said, as learning, to do it constantly and actually it's kind of counterintuitive, but be happy for some failures, because you have some data, you have some feedback from the market, and that's really a gold value nowadays.

Paul Aston: Absolutely. And, I mean, if you think about how much you can spend on a market research or a user testing agency, in some ways, it can be better to just spend that money and build and put to the market and get, you know, get that learning yourself. And I think... Something else in there that I think is very interesting is when you're dealing with a company that hasn’t tried digital before, you have to make sure that you educate as you go. So never, you should never be saying: “Well, of course, we'll build this and it will be amazing.” You say: “We build this. This is our first iteration, this is our best guess, but it may not work. There is every chance we will need to change.” The process is iterative, be prepared for iterations. ‘Cause otherwise, I think you’re mis-selling the product. There's no such thing as a short winning.

Attila Tóth: Indeed, indeed. And I think, with this current situation with COVID-19, it was kind of like an eye-opener for many companies that it's time to think of digital products, but those on the other hand, what I experienced is that many companies are not aware of what's happening behind, and they are expecting just immediate results. In your case, how did this pandemic affect your responsibilities? What threats, challenges and what kind of opportunities do you see on the horizon in your area of responsibility?

Paul Aston: I mean, within my personal sphere, I think I was – I don't want to use the term ‘lucky’, ‘cause what’s happened has been a horrible thing, and there is no luck in there, it's more I was fortunate in how things work, let's put it that way. The product that I'm working on is already about taking services and digital products direct to consumers and business as well and doing it in a way where we actually remove a quite large element of human interaction overhead. So in terms of releasing our APIs, for example, as public, we are creating gateways, we are creating account handling work, creating a legal framework that could be dealt with online. Previously the path would often be we would meet company, we would put together a partnership agreement, there would often be, you know, quite a lot of face to face, which these days is obviously very tricky. We were already working to remove that, so if anything, I think it just reinforced our argument that people shouldn't have to come to us and find us, we should be reaching out to people to show them how easy it is to start interacting with and using the Volvo toolbox without necessarily having to come and find the Volvo in person. I mean we just recently did a super early alpha release of a concept called ‘direct the vehicle’. This is part of a larger ongoing project, where we’re enabling service providers’ businesses to connect with a Volvo owner’s car and find its location, interact with it, and unlock it, all without needing a key or needing to meet the owner. This is a way that we can start creating a kind of a contactless future, which is beyond contactless payment or something like that. People can still fulfill services around a vehicle without having to, in any way, meet or interact with the driver. There’s no handover of a car key, where you’d want to spray it down with like a hand disinfectant or something. So I mean, in my sphere, I think it was just a reinforcement of what we were looking at. I mean, Volvo as a whole, has already started to move towards direct-to-consumer, so we have care by Volvo, where you subscribe to a vehicle, you don't need to go to a dealership. You go online, you choose your car, you click ‘Order’, everything's taken care of, and then you can go pick up your car. And we have a digital key, so you can use your digital key to unlock your car if you want. And there are a couple of great initiatives, where we did more on that, you know, trying to bring as much of the physical Volvo into the digital space, so users can find and play with those. I work with an amazing guy, who does a lot of work pushing our VR space. And this is gonna be very interesting to explore as well, I think, in the future, as we can create a virtual showroom. You can, you know, put on your headset, and in your living room, you can explore your potential new car. So all these things were already kind of coming along, and then we had this pandemic, which reinforced the sense that people are stepping away from traditional bricks and mortar. Going back to my role, if you’d like a challenge in there, I think the biggest challenge for me was the human element of my team because we all quarantined at home, we were all working from home, we were disconnected on a personal level. So, as I mentioned earlier about being a product owner, one of the things you do is look after your team. You want to lead them, and leading your team when you don’t see them face-to-face becomes quite an interesting experience. You lose a level of empathy, ‘cause you’re not there in the room with them. So a lot of my work has been around finding ways to try and make sure we stay connected, stay engaged, maintain our team culture, which has always been really important to us, and maintain the social bonds that made us such an effective team.

Attila Tóth: Cool. I’m really curious, ‘cause I think many companies are facing these kinds of challenges. If you can share any ideas… What do you do to maintain this social element of teamwork?

Paul Aston: Couple of good things. We tend to be very active on Slack, which is really good just for being really stupid. And that was kind of what we pushed for in the end. One of the problems you get into is you can just follow your usual daily routine, do it digitally, but then you miss the people, and we always have a daily standup, and that’s what always kind of been… it’s a very key part of our culture, but what it always tended to be was daily standup, and then we’d hang out to talk. So I got rid of the usual standup rules. Rather than “What are you working on?”, “What have you worked on?”, “What are your blockers?”, we just do a daily topic. The first couple of days, it could be anything from, you know, “What’s your favourite hack?”, “Show us a picture that’s hanging in your house and tell us about it.”, “What’s your favourite recipe?”. Then we do an official work-check in the middle of the week, and then we do social questions, talking to each other the rest of the time, and then any problems, queries, anything like that tend to get talked through on Slack, where you can then pick it up, do with it as needed, or take out little break-out sessions. And then at the end of the day, that’s when we do a stand-down, where we talk about the work we’ve done, we get screenshots, we see little videos of cool things, and that has actually been super effective. And the morning standup, where we hang and connect with each other, I’ve got to be honest, is a really high point of my day, gives me a huge sort of energy boost. It’s just so nice to see everyone’s faces, have a laugh, have a joke and connect with them.

Attila Tóth: I love that. Product owners who are listening to this, copy-paste this idea, because I think it’s really brilliant. Thanks for sharing it. Going back a bit to the Open Innovation Platform. I know it’s a new thing. Could you tell us a bit more? What’s your role in it, and what’s the future of it?

Paul Aston: Ah, as I said my role is… it’s been taking it from an embryonic e think this could be a good idea. How do we prove it?” through to “We have now launched.” It was a soft social launch, just trying to test the waters on something early, given the situation we’re in. But what I found is starting from scratch, the initial research looked into benchmarking our developer portals, what people want to engage with, looking internally into the company: what do we have to offer, and also, I think quite crucially for our project is we’re looking very much at what can we offer to the people within the company. Because very often, you have a developer portal and it’s the flashy front end of the company, and then their own developers are still scrabbling around with poor documentation. So we’re making sure that the internal part of this is just as good and just as polished as the external part. I just worked very small steps, taking it through the initial concept. We did a super small test launch of a single-page at a hackathon we went to, where we just pulled together some cool digital tools, put it out at the hackathon so people would just find it, monitored and checked the analytics all over it so we could really get a sense of how people used it, and that one of our first kind on really good learnings. And then… Working with our strategy guys to understand what it is that the company is hoping to achieve, trying to formulate exactly what it is that I would like to achieve with this, and then looking at all the other products we have. So I think one of the big challenges with this is being the portal, we don’t own the products, we’re not creating APIs to make public, we’re not creating 3D models, we’re not creating an Android Automotive emulator. What we’re doing is we’re working with the teams who are creating these and trying to facilitate the best possible way for them to expose them, so a lot of alignment with those guys. Sometimes, it’s kind of the gentle nag of “You said, this would be ready last week. How are you getting on? I’d really like to get something out. Is this possible?” To other teams, it’s been maybe even more hands-on of: “Okay, you’re blocked. We need to do this. How can we help? With what can we contribute to get this product out?” So that’s taken us to where we are now, where we’re coming into the Sweedish summer holiday. For those that don’t know, Sweden has a tradition of the industrial holiday, so at the beginning of June, all of the factories would close for four weeks. So everybody was guaranteed a holiday, and this is a tradition that’s carried on, it’s almost like a Sweedish human right that you take this long vacation, which means that we now are very much hoarsed. Nothing will happen until we get back. So my work up until the summer was getting this new launch out, and then a lot of work lined this up for coming out of the vacation time. And then that’s where it’s gonna get super exciting for us I think. That’s when we have, if you like, our big launches. We’re going to probably start with a 3D simulator, which is just the most incredible toolset working with Unity, where you’ll be able to download a model of the car, interact with it, put it into any of your own projects. You can pretty much do whatever you want with this Volvo, it’s super cool. After that, we will have the Android Automotive emulator, so using Android Studio, you’ll be able to develop in-car apps and preview them and test them on an interface that looks just like that in a Volvo car. And then, after that, we will have the first launch of our public APIs, and so then people will be able to access the APIs that we use at the company and use them for their own projects.

Attila Tóth: Mm-hmm. Really futuristic. I love how you think it and I think Volvo is ahead of many corporations in working with digital and thinking futuristically because I see there are many brands out there who are just now thinking to tap into digital. They might have used it some way but as you said, strategically it’s not yet on the table, so congratulations for that. How would you advise management boards and key stakeholders to think of digital products?

Paul Aston: Hmm. Good question. I think the first thing I would say is digital is not the answer to all of your problems. I come up a few times with companies where they seem sort of think that by going digital in some way then that is what the market demands and this will solve all of their problems. That’s a real fallacy. I think what you should think of digital products is it’s part of your toolbox, and it can be a solution to a problem, but you need to identify the right problem and then make sure digital is the right solution for that problem. I’ve seen a lot of companies that rush headlong into some kind of transformation without understanding why. They just feel that they should. I think it’s far better to take a core problem and then test it and evaluate it. See what works for you and then build on that, build on a solid probation. If it’s something like, if you are a traditional manufacturer and you sold retailers, well perhaps the thought might be now is the right time to go direct to the consumer. So then test something simple with direct-to-consumer and then build it. If that doesn’t work, then perhaps digital is the wrong solution for that particular problem. But then revisit, adapt, understand, what is you need to do and then come back to it.

Attila Tóth: I completely agree with you. I think first you need to have a strategy before you invest any euros or any pounds in digital because otherwise, you might just, as you said, rush into a project which will not have the ROIs that you are expecting, so strategy is key here. And usually, business decision-makers don’t see behind the curtains of creating digital products and only see the success and usually the success of the competition or the success of other brands or scale-ups or startups, but we already discussed on failure, but if you could share, maybe some darkness, let’s go a bit to the dark side: what was one of the toughest setbacks you’ve ever experienced?

Paul Aston: Ohh. Toughest setbacks. That’s a good one. I would say the toughest setback I’ve ever had was some time ago in previous projects, realising I had completely failed to get any kind of stakeholder or even internal buying to the product I was working on. So working in a way where I was looking at a problem and when this is it, we have an obvious solution, this is the way to do it. We will work on this and of course, we’ll present it, we’ll be the heroes to have solved this problem. So there was a lot of time and a lot of money and a lot of people power invested in something. And then we came along and the response was very much 1. We didn’t ask for this 2. Why are you working on this, there are three other teams working on similar things? Also, who are you, because we haven’t met you in any part of this process and what are you doing here? And so what we thought would be the grand triumph was actually a very damp squib and actually created some bad feelings between a couple of important people in the company. And that was a very valuable lesson to learn. Always, always, always engage in the process, make sure you have people who know what you are doing, who bought into it, and also make sure of what you’re building is actually wanted.

Attila Tóth: Wow. Thanks for the openness. I think from these stories we can learn the most and the audience can definitely learn from these lessons because this is kind of like a typical example in the corporate world of a mistake what is usually done in the startup world, where don’t share their ideas with anybody, not even the market sometimes and they believe they are working on something great, and then when they put it on the table then nobody really wants it, so thanks for sharing this. I didn’t hear any similar story in the corporate world but yes, it could be a real setback.

Paul Aston: Yeah. It was a humbling and good learning experience. I think as you say, too often we tend to do that thing of: “I have this idea. This idea is great. I must protect my idea. If I tell someone my idea, they will take it from me.”  But it’s actually the opposite. If you have a good idea and you share it and people like the idea, people will very often support you in your idea and help you along the way. And these people then are also gonna […] shared ownerships, it can become open source. And so there isn’t just one person working on a product, it’s a team of people, a family around and so that product will always have so much better support so don’t play your cards close to your chest, play with transparency and you’ll go much further.

Attila Tóth: Thank you for that. But hey, let’s not talk only about the negative. What would be an accomplishment that made you really proud and how did you achieve it?

Paul Aston: Ohh. Accomplishment that made me really proud... It’s difficult because my background as a developer means that I’m never happy with anything that I launch, so I sometimes struggle a bit to sort of really look at something with clear eyes and go: That’s great! So what I would actually say is right now what I am incredibly proud of is the developer portal and that is because I’m very proud of the team that I worked with, everyone who’s been involved in the process has been fantastic. It’s been a real pleasure to work with all these guys, and the energy and the creativity and also just pure competence. So I wouldn’t necessarily say it's pride in my work, but I’m very proud of a lot of people I’ve worked with, I’m proud on their behalf and the fact that we got over that milestone, especially in corporate where we launch something in a public .com domain, yeah, that right now, I’m insanely proud of.

Attila Tóth: Thanks. Thanks for sharing. And just to give guidance for let’s say for upcoming product owners or why not, product owners who are already working on projects: what is the path to succeed? What are the steps you usually take to make sure you are heading in the right direction.

Paul Aston: I would say first things first: start with insight. Insight can be pure data, it can be market research, it can be socio-ethnographic studies or it can even be trend analysis you do yourself. But anchor your thinking in reality or least a version of reality you can find and understand. Start with a solid base. And then build up from there. Always understand what is the problem I am solving or what is the question that I am asking with this product. Because it’s very easy to kind of say I think this will work and I see from studies that there’s a gap in the market for this thing. And then you start building and you go so easy to get deep into it and you start conceiving features and the flow and everything and before you know you’re building it. We always talk about the fundamental unknown. What is that keystone of your concept, there is gotta be something in there that is your first big assumption. Test that first, get to trying that out in the cheapest, quickest, easiest way possible before going any further. So think in terms of steps of experiment rather than ok, what do I need to do to build this product out. Test this primary unknown, make sure you are building on a solid foundation. Then what is the next thing that you need to test and make sure you are correct on? Because you are gonna rework a few of your assumptions. So build in a way that allows you to test each of these assumptions and make sure that each time you test if you’re correct, great, keep going if you’re wrong, understand why and pivot. So that way by the time you get to some kind of release, you’ll build on the most solid foundation you can have. You'll still may be operating on some other assumptions, but at least it’s your best possible guess based on your best possible insight.

Attila Tóth: So a lot of iterations, basically that should be part of your strategy. Right?

Paul Aston: Absolutely. Always make sure that you are testing. If you just have pure belief that will take you so far, then that belief often becomes one of those products that is released, gets ten users and how someone sitting there, going: ”Well, clearly the public are wrong. This is fantastic.” Do your Due Diligence.

Attila Tóth: Cool. I love how you put this process and thanks for the guidance. I just want to tap into the details here in terms of: what is your process of connecting creativity with technology and how do you keep a business-driven focus because I see on one hand many creative people who just can’t really connect first with technology and can’t move forward and then even if they connect it then they’re usually losing focus and not serving a business problem anymore. So do you have any recommendations on this?

Paul Aston: I would say the key thing is your team. [...] If you have a digital product, it shouldn’t just be a room of developers, and it shouldn’t be one of those instances where you start with UX and a designer who comes up with something and then give it to the devs to build and then just sort of leave it. And also it should definitely not be a purely business-driven product design because then it can get very messy and ugly. So have a team who work from the very beginning of the project who come from all disciplines. So we often start with a design sprint and in that design sprint we’ll have UX design, we’ll have tech, we’ll also have a business designer or somebody who understands building the business model. And so from that, what you are able to generate is we have the classics: design sprint, initial prototype that you wanna test, but we will also have an underpinning where we have a clear hypothesis of what we believe, we’ll have our value of exchange, we’ll have some kind of breakdown of what’s the value proposition in all of this. And underneath that’ with all of those things we have what are our unknowns in tech, what are our unknowns of users, and business and then that’s when we get into the process of beginning to iterate and test these things. I think if you’re trying to divide it up or do one bit at a time, it will never work. You need to start by getting all these guys in the room. Then you can kind of break it up a little bit and make sure you focus on those areas where there will always be expansion-contraction, expansion-contraction and everyone coming together to work together. Otherwise, one of those elements will fall through. That would it be, again it’s not a guaranteed path to success but it’s a really good foundation for it.

Attila Tóth: Fully agree. So having different perspectives, different mindsets, different expertise already involved from day zero, it's critical. Thanks. Thanks for putting it so nicely. Good! Let's play a bit of a sci-fi game. If you would be able to jump ahead 10 years in the future, what would you see? What would you be doing?

Paul Aston: Ohh! Well, let me see. If we say...  what I’ll be doing right now 10 years in the future. So, we're speaking and it's 1 o'clock in the afternoon. I would imagine, it’s gonna be 1 of 2, right now, if you want 1 of 2 potential scenarios. One would be: I would be at home and I’d be working, I think something different from now is that remote working is really not a problem even for large corporations, so my office is going to be anywhere where I have a strong, stable internet connection, and I think the lines will have blurred significantly between work-life balance, between the meanings of specific buildings and spaces. Right now... It used to be that you live in your house, you get in your car, you go to your office and then you go backwards, I think now we are just moving through the environment and at particular times of the day that may be a time when we are working, and I could be doing work-related things in my home, from my car or from my office. Likewise, I could be taking care of life admin and just so happens it’s more convenient that I’m doing it from the office. So, I think we will see much more of a blurring of lines, I would like to think, and that's gonna have some significant societal changes. There’s a lot of talk around things like autonomous drive where... well, the car now becomes kind of a liveable space: I’m in the car, but I’m not actively driving. What do I do during this transition period? And so much has been done about all the work that the car will become a workplace, it will become an entertainment centre, it will become something other than it is and I think what we should be doing is looking at it's not just the car, everything will have that same transitionary shift in becoming a space other than it was originally seen. What will I see? What I’m… like 10 years is maybe too soon for it, but what I would like to think I see is more green, potentially… I don’t want to say less vehicles on the road, ‘cause I work for an OEM, but vehicles moving in a way that is purposeful and meaningful. And I say that meaning that a personal vehicle is only used about 10% of its life actually to be driven, the rest of the time, it sits. Perhaps, you’ll be subscribing to freedom to move, but you’ll be doing it in a way, where you don’t have a specific lump of metal sitting on your driveway. I think there’ll be greater work on the environment, I think we’re starting to hit some global sustainability goals and so I actually think that we’re starting to see a world where the ravaging of the last two decades are starting to be reversed, and large corporations will be taking responsibility for their part, but also people will be taking responsibility that will be just part of the everyday. That’s my hope, at least. I love the idea of, you know, the bright, shiny, white technology-future, but I actually think we will be leaning more towards, hopefully, a more natural, cleaner, brighter future.

Attila Tóth: Hmm, I love that. I think it’s a great vision and one vision definitely worth living for, so yeah, it’s a great thing to think of, and as we are closing to the end of our discussion, I would have just one final question. If you had just on advice for enterprise businesses, for corporations about digital product development, what would that be?

Paul Aston: Let me think… My one piece of advice would be: do not necessarily think that you could do it yourself and just elevate internally somebody who would then take it on a challenge. It is very much a time to take a step back, look outside-in, and think that you should bring in subject matter experts in digital product development, you should bring in a team with experience, and then what you should do is to set them up to fail, and fail often, and fully support it without necessarily trying to enforce traditional business development methodologies. Maybe that was two pieces of advice, but it rolled into one.

Attila Tóth: I think that’s a great closing note. Thanks for that, Paul. I really appreciate your inputs. You’re one of the few guys, who really likes to experiment and lead by example, a great role model for product owners. Thanks for joining the show.

Paul Aston: Happy to share!

‍