Susan: [00:00:00] More 2 Marketing. Welcome to More 2 Marketing the podcast that explores marketing
product and everything in between. I’m your host for today, Susan Walsh, and we are here talking about product delivery. I would like to introduce you to Jason to help unravel what product delivery is. Jason, how many years have you been doing product delivery for.
Jason: Oh, Susan, that’s a tough one. Probably close to 20 years now, I would say. Oh, wow. So over, uh, in Telco, mainly with, um, Optus as being the, the prime candidate of where I’ve been. But I’ve also done it in, um, NBN Co and um, Salma Plus also a bit in Services South Wales. So a government view of that as. . Oh wow.
Susan: So really technology, um, is key to the businesses that you’ve worked on for [00:01:00] your product delivery you’ve done. Yeah, absolutely. So what type of delivery pieces have you actually delivered that we may know of? Um, anything that really top of mind that really excited you or was a bit difficult that you were able to deliver?
Jason: Yeah, so my current role is a hybrid between product development and product delivery, which are normally two quite separate roles where you’ve got the product, um, development team that come up with the requirements and say, I want a product that looks like X, Y, and Z. Then you’ve got the product delivery.
Person or side that actually takes those requirements from the product manager and then turns it into reality. Um, I think in the product delivery side is very sort of, um, a me a mechanical sort of process. That you get the recipe. So you get the ingredients, which are your requirements, and then you work out how you’re going to build it, like a recipe.[00:02:00]
And then at the end, then you get to taste the recipe to see what it’s like, um, in reality. And then, so next time around you do it. You can tweak the recipe, add, remove ingredients as you. So I think in the product delivery side of thing, I’ve been involved in a lot of different products over the years. I think one of my most interesting probably was the development of 4g.
When we released 4G to the market in 2011, that was a game changer too. Absolutely. Like that was a big step change from when, um, 3G was around. So the iPhone 3G was there. Um, iPhone 4g, uh, when it came out was, um, a game changer. But I think Samsung actually got there first. So I was lucky to be part of that 4G launch party.
I was the, uh, in the product [00:03:00] delivery team, working through that with our networks team and all the technical people. So I sort of straddled the business and the engineers to. Make 4G a reality work with, um, quite closely with Apple for the launch. But as I said, with Samsung, we actually launched the, let me think, the Galaxy S two 4G back then.
Susan: Oh, you’ve got a good memory.
Jason: Yeah. And so I, um, traveled the country and, um, had to train up all the sales staff about what 4G was and sort of did a Steve Jobs moment at once and held up this new prototype phone and said, this is the first new 4G phone that’s going to market. And someone in the audience that was supposed to be an only an internal meeting, briefing someone took a photo and forwarded it to the press and.
then it just went a bit crazy from then. So I sort [00:04:00] of, um, sort of leaked some of the info accidentally. But yeah, that was, um, an interesting, um, experience to be through that whole let’s change the world with 4g. And as we know, we’re, we’ve been living and breathing 4G for the last decade. Now 5G is following a very similar.
Pattern, every G that comes out is every 10 years generally in Telco. And so 5G is followed a very similar pathway to 4g. And I would assume that six G will do the same. Yes. There’s always going to be a future delivery to do, isn’t there? Yeah, absolutely. Uh, that probably comes down to, um,
Susan: my very first question for you is what does a product delivery manager actually do for their core role?
So what’s your, every day or every week, activit?
Jason: So in product delivery, uh, depends on the methods. So there’s different methods of how products get taken to market. There’s [00:05:00] agile delivery and waterfall delivery, and that sort of, um, dictates what, um, events happen or activities happen every week. Primarily at the moment I’m working in a waterfall type, um, development or delivery mechanism.
And so Waterfall is, here’s a predefined scope. Here is the time. A lot of the things are already known, so. You have the ingredients, you have the outcome, you know where you want to be in say, six or 12 months, and you just deliver it. And so there’s a defined scope for that. And that scope then gets, um, um, validated from the beginning.
And so this is Optus, um, development talk at the moment, but we’ve got a different phases of delivery. So there’s, uh, initial investigation or ideation, and this is where the product. Um, owners or product managers [00:06:00] say, I want this delivered in this time and this is what it needs to look like. And you go through all that high level requirements.
Um, then once we’ve got that sort of solidified and then you can sort of guess where it’s going to be. How much it’s going to cost, what resources you need. You’ve basically got a skeleton of what the product and the project looks like. Mm-hmm. , once you get that skeleton, then you can go to the business and say, is this what you want?
Can we move ahead? And you’ll probably have a funding gate at that point, which then dictates, okay, let’s go into the next stage. And in opt to speak, that was feasibility and definition, but also a lot of places called a detailed design instead of high level design. So that next point is where you work with, um, business analysts and change managers and product managers [00:07:00] and engineers.
The IT and the delivery teams, um, to build the detailed solution designs or documentation on how you’re going to build it. Mm-hmm. And so that then gets you to a point where it’s like, Plus or minus five or 10% of where you need to be as an estimate. Then you go back to the business and you say, okay, we’ve refined our design, we’ve worked out what works and what doesn’t.
Susan: The risks level has come right down, so then the business can say, go, no, go. Let’s go into the build phase. And so mostly that Why’s so important to do that scoping, isn’t it? To make sure you absolutely get that risk down to that small amount so everyone knows what’s going to be deliver.
Jason: Yeah, so you’re iterating it.
Think about building a house where you go in, you. I want a house and someone will say, well, how many bedrooms, how many bathrooms? So like, is it two story? Do you want a driveway? Do you [00:08:00] want to semi detached? Or are you happy with an apartment? What’s the location? All of those sort of things is, is the initial investigation idea, and that gives you the rough costing of the house.
Then you’ll go into, okay, well I need to get funding approved from the banks to go ahead with all of that stuff. Based on that which you do, you go to the bank and you say, I want a mortgage, and blah, blah, blah, blah. At that point, then, if you’re getting a bespoke building, so not one of these kit homes that have already had it designed, you would then get your architect to draw up detailed drawings and start engaging the contractors and looking locking in resources and locking in.
Um, do you want stone bench tops? Do you want wooden floors instead of lino or tiles? All of that sort of lower level detail is that detailed design phase. Before you actually go out and buy stuff, you need to get that inventory of what you want in [00:09:00] your house. This is the same thing in product. So then when everyone’s happy with that detailed design and the actual texture drawings are done and all this sort of stuff, then you get that final approval to say, yes, that fits within my budget, or, I know I need extra mortgage to cover all my requirements because I added an extra bedroom at the last point, or I’ve added a second story.
All of that sort of stuff then has to be recalibrated. Then you go into build phase, which is the same in product development that it is in building a home. So you then get the engineers to start building all the requirements, the servers it to start coding the requirements. The business has to start writing all the processes and the go to market team have to work out how to advertise this thing and how to price this thing and all that sort of go to market.
Activit. That’s during the build. Then once you’ve [00:10:00] got something that’s already built, then you need to test it. So that’s where you get your, what Optus calls it, and it’s different depending on which company you’re working in. Sit, U A T, B R T. They’re the three phases that we use for testing, system integration, testing or sit is, um, testing individual systems and then how they talk to one another.
So you’ll get system testing, which is individuals systems. You’ve got system integration testing, which says system one speaks to system two and transfers the data and everything talks one another, and that’s fine. And that’s still within a test environment, so to speak. Um, so it’s not in production. Then once sit exits and we sign it off, you write your test plan and you write your test cases and you get your test summary.
For sit, you go into the user acceptance testing phase. Um, sit testing is [00:11:00] done by IT and engineers, and not the business, not the end users that are using it. User acceptance testing is where the end users get to use it. In a test environment. So this is the business, the sales people, possibly even the customers playing part in that user acceptance testing.
Susan: Um, yeah, it’s always good to go through that, isn’t it, just in case you have to do other small tweaks or anything.
Jason: Yeah. Yeah, yeah. And that’s sort of where the agile approach sort of comes in, where it, the, uh, the user voice or the voice of customer becomes very important. But in a waterfall, the most requirements are met upfront.
So the product manager or the product owner dictates on behalf of what the customer is. what they want, so you’re not getting that direct feedback from the customer. Mm-hmm. in a waterfall type environment. You can get snippets of it in user acceptance testing where selected end users, but you may not have use cases tested for [00:12:00] all the different types of users.
You might be very selective with what you are testing and how you’re testing it. . So then once you get through that, uh, u a T testing phase, then you would move into, um, going in, going live or going into production or rfs. There’s so many different terms for turning that thing from a test environment in the test servers and putting it in your standard b a U production environ.
And merging the code and releasing it into the wild and seeing how it goes, and I’m suppose in that could either be in your own ecosystem or you give other people access to it to be able to utilize it. So it’s got multiple purposes once you’ve created this product. Yeah, yeah, absolutely. So when you put it into production, you then release it in the wild to a limited number of real users in the wild.
Mm-hmm. . And we call that business readiness [00:13:00] testing. So that’s where you get to test the systems in production, that everything that was done in the test environment works the same in production, that the processes are working. That all the people are there, they understand what they need to do. All the go to mark is ready.
It may be hidden or it may be visible to the wider world depending on how you’ve released that stuff into production. But b r t is is an opportunity for you to give finesse the finer details that, oh, you’ve missed this, or we need to tweak that. Or maybe we need to say, no, it’s a no-go. This isn’t going to work the way we expected.
and then reenter back into a development stage or another testing cycle in the test environments. So you’ve got these multiple gates with a waterfall process that you’re refining, you’re refining, you’re refining. You finally get to the end of B R t where you’ve got a subset, customers that are like, yep, let’s go ahead.[00:14:00]
let’s go. Then you go live or you go above the line or there’s so many different terms and it depends on it and networks, say RFS or ready for service. Yep. Where Go Live is more of a marketing, marketing term. I like live market myself. That’s . Yeah. Yeah. So, um, going back to that, the Agile process itself.
Susan: Yep. , there’s a lot of commentary out there about waterfall versus agile. Is agile just another type of waterfall, just, um, snippet it up a little bit more into sprints as they call it. Yeah. Um, what do you think when it comes to the delivery part? Well, I think. There’s two different ways that you look at agile versus waterfall.
Jason: Sometimes if you are starting from scratch and you don’t know what you’re building and you dunno where you want to be, and you are using a voice of customer to help develop that product for you, then you go the agile approach [00:15:00] and Agile was very iterative. There’s a lot of, um, events and there’s a, a predefined process that helps facilitate that change into sprints and use cases and all of that sort of delivery items for Agile.
Um, plus all the ceremonies to double check stuff, plus also to reward people for doing a good job or to incorporate feedback where things need to change. Where waterfall is, it’s very, uh, regimented, very strict. The change management process is, it’s designed that the path is already drawn for you and you are not really going to deviate from it unless you really, really have to.
Susan: So it depends on, on the scale. .
Jason: Yeah. You wouldn’t build a big, massive 12 billion freeway in an agile approach. Mm-hmm. , because it did look, is. [00:16:00] Yeah, the freeway, you know where you’re starting, where you are ending, you know what needs to take there. You know you’re not going to deviate. It’s a straight line.
You go there. That’s a waterfall approach. Agile is like, eh, we don’t really know what we want. We don’t know when. Then you have to zigzag through your. Um, pathway to the destination. So the it, what I think happens is that you build your product initially in a waterfall type situation to get you to that M V P or minimum viable product.
Then you can then switch over once the product is live and um, in the wild, you then toggle to an agile type approach to iterate it from that version one into subsequent. So build it in mortar for version one, agile at diversion two and beyond. Yep. Yep. Your two point ohs, et cetera. Yeah. Yep, yep, yep. Nice.
Susan: I, I really love the analogy of the house as well. I think a lot of people can actually [00:17:00] understand that approach to it and actually be able to picture it as well being built along the way and all the different processes you have to be, have to go through in some of those loops as well.
Jason: Yes, absolutely.
Susan: Uh, my, my next question is going back testing. There’s a lot of places that I know don’t test, um, and other places that are rigid on testing. How important is testing during these processes and why companies and people should invest in it?
Jason: Testing is probably one of the hardest challenges. We’re in product development primarily because we know when things are being built, things go wrong and time slips away.
If you’ve got a project that has to deliver by X date, . What happens is that date generally doesn’t move either the scope changes, so you reduce the amount of work that you’re building or you compress everything into all those milestones get closer and closer. What generally occurs is [00:18:00] that the testing schedule goes from eight weeks.
Down to six, down to four, and it, and then the different milestones of testing start overlapping. Instead of having clear delineations between C U A T B R T, you find that, oh, we’ll overlap U a T and with B R T. So whatever test cases have been done in sit already, if 50 percent’s done, then you start U 18, those 50% have already been done in.
and then the remaining 50% of sit will be done, and then the remaining 50% of U a T will be done. Mm-hmm. . The challenge with doing that is a lot of the time it’s the same resources doing the SIT testing versus the U A T testing. Yeah. So it’s almost like, why am I testing this? And then two weeks later testing it again.
in the same environment. So what you tend to see is C U A T gets blended into a pre-prod testing. You don’t get that clear delineation [00:19:00] between the engineers testing it in sit and the business testing it in U A T and the test environment. The business does all the testing on behalf of the engineers and then exactly the specialty.
Yeah. The problem with that is the business is picking up defects and faults that they don’t understand, a, how it happened, and B, how to fix it. Yep. So then you have to hand it back to the engineer. They then have to retest that in a SIT type of function. Then they have to get the business to redo it again in U A T.
So yes, it does sort of muddy the waters and blend it all together. and the problem is then you get a four or six week timeline for that pre-testing down into two or three. It’s really stressful, but if you choose not to do it, it’s always harder to A, identify the issues in production with real customers.
B, once the um, product is launched, it’s very hard to [00:20:00] pull it down and fix it if it takes a couple of weeks. So then you end up doing a lot. Production hot fixes, which are just every night, just tweak this little one, tweak that little one, but you can’t really fundamentally change how you do things. And you’ve got that sort of, um, issue of hindsight.
I wish we hadn’t done X, Y, and Z, but you don’t get those learnings until it’s too late. . And so this is the challenge that yes, you can compress your testing, but it’s a double-edged sword that you will feel the pain in production and then you can basically have to live with it. Yeah. And, and it, I’ve, I’ve been through this myself and it is very difficult one, asking people to, to compress and do it faster.
Jason: And then when you’ve launched something, having to go back cuz having to go back is hard. Um, even from um, my side, which is the product side, cuz then you’ve gotta do potential detrimental and all sorts of things that might come along with it. [00:21:00] Yeah. I really appreciate you going through that, that detail.
Susan: Jason, I’ve just got one final question for you today. Yeah, that’s fine. My last question, which, um, I will, I’d love to ask is what brand you can think of any in the world? And I did steal this from someone that I met at Optus. It was one of their questions. Yeah. Um, what brand best represents who you are and why?
Jason: This is a tough one. I and my view has changed over the years. I used to have Apple as the brand that used to be there. It was quite innovative when, when they brought out the iPhone, they changed the world. Yes, that one product changed the way society functions. Everyone does everything. Differently what we did, we didn’t have mobile internet, we didn’t have Facebook, we didn’t have Instagram, we didn’t have Google Maps.
There were so many new ideas that came out of that one innovation [00:22:00] that changed our lives forever. And that was with Steve Jobs, he was an innovator. He didn’t compromise his requirements or his, um, standings and, and his standards. But unfortunately, I don’t know. I think Apple is now so dependent on that one product.
Mm-hmm. , that they’re now scared to change that product. Yeah. Cha change. Yeah. Scared ofs to keep the market share. They’ve gone from a challenger spirit to an incumbent. Mm-hmm. . And when you go from an incumbent, you lose that innovation edge. So I would have to say now, Probably Tesla. Like they’re doing a very similar thing to what the iPhone did for cars and changing the automotive industry.
Yes. And I don’t always agree with what, um, [00:23:00] Elon Musk does and how he does things, especially the Twitter debacle that is funny to watch. Sometimes you need to ruffle some feathers and change the way we do things, b a u and how people think as well. Yes, absolutely. So the, the car, what Tesla is bigger than the top four other standard internal combustion engine car manufacturers, like they’ve gone from going bankrupt to be the biggest capitalized car company in the world.
That doesn’t happen by incremental small changes. He is changing the. For the good, we hope for the environment definitely. And for society at large. Absolutely. Um, how we get there when all the other car companies now start to have to iterate and innovate to catch up, whether they overcome and overtake him, who [00:24:00] knows how That’s all going to happen over the coming years.
It’s really exciting to see what happens with Tesla. I know it’s, it’s not the. Place to work. I hear people having to put in lots and lots of hours and and that’s you as well, working from home. Yeah. You’re always passionate and, and, and getting all that done as well, so yeah. Yeah, I, I can see the synergies there.
Susan: Definitely. Absolutely. Oh, fantastic. Thank you again, Jason, so much for today and don’t No worries. Forget to add More 2 Marketing to your playlist so you don’t fit. I miss out on any future podcasts as well. Thank you. Thanks. Thanks, Susan. Thank you More 2 Marketing.
