 Okay. So this is my natural place standing in front of people and yapping at them. So if I get to talk with you and not listen to you, please let me know. So in this little session, and I want to really thank you for the opportunity to have a quick chat with you. I think it's always good fun to talk to other people and share your ideas. But we're going to talk about a little story about six simple rules of product management. So because I haven't plugged in, no, I haven't turned it on. Uh-huh, power switch doesn't do it. So as we were just being introduced to, we're from, it's about a short night from BrainLates. We're a product manager training consulting business. And why we think that's important is because we train what we do, we do what we train. And so if it doesn't work in the real world, we change it so that it works in the real world. And, excuse me, what we've done over the years is we've found really good ways to make a lot of sense, but don't work in the real world. And we've continually optimised them so that we can use them practically, and that becomes part of our core training course. My name's Nick Costa. I'm one of the co-founders of BrainLates, along with Adrian Tan. We've been doing this BrainLates thing for over 11 years now. So being professional product manager and trainers and consultants in that space. And together we've both had over 20 years of product management experience in the telecommunications, the new media, and you name it, we've been able to apply the product management thinking to a wide range of different industries and services. Okay, so today's topic, and this actually came from a conversation we had, so I gave a presentation earlier today, and we were asked to do a bit of a talk on the topic of how can we bring ideation quickly to market and meet the customer's expectations of the product. And so I've kind of used this as a starting point to talk about the six simple rules, because it's not unusual for people to say, hey, I've got these great ideas, how do I get them to market, and then make sure the customer's like them. And so we'll kind of use what we refer to as our six simple rules to sort of restate this question in a way that's actually more practical and useful for any business to think about. Okay, so there's this, we use our six simple rules. And the idea of having six simple rules is that it's easy to make two complicated rules, or lots of complicated rules, they have a big methodology. And when we sat down and thought in terms of the product management space, the practices in product management are changing. And there's lots of different competing or almost overlapping methodologies that are being applied. So old school is waterfall where you came up with an idea, you'd flesh it out, you'd write a requirements document, you'd build another requirements document to meet the other requirements document, you'd hand it over to the development team, they'd build it out, you'd launch it and realise that three years ago it was already out of date. And so that didn't seem to work very well. And so new methodologies like agile and lean and customer-centered design and service design, are sort of popping up in all directions. And really over the last 10, 15 years, they've sort of become more fashionable, but they're trying to do the same things in slightly different ways. And so when we look at these, it's easy to get down in the detail of if you're doing agile, you're doing scrum or type of scrum, you're doing can-band, get into all this sort of deep terminology. But if people want to adopt it quickly, we wanted to have simple rules that kind of covered all the bases, regardless of what methodology we were talking about, that enabled you to understand or kind of frame that thinking no matter what kind of process or method you're using to do stuff. So these six simple rules are essentially short-cut strategies so that we can remember them and implement change in organisations very, very quickly. So here are six simple rules. First rule, customer first. Now it's a sort of rule that everyone goes, yes, customer first, we've got a customer, they're wonderful. And then we've got to build some stuff and realise the customer doesn't want it. So when we mean customer first, we mean before we have any conversation about the product, we should know who our customer is, we should have met them, we should have had a conversation with them, really understood what their pain points or frustrations or needs are as part of that discussion. If we don't start with the customer, then everything is broken everywhere beyond that. But the way we treat things is kind of like we've given you the product and the customer goes, oh, I love you so much, you're the most fantastic company in the whole wide world. I wish you riches and happiness forever. But that's not how customers are. Customers couldn't give a crap about us. We give them something, they pass the money and they leave. So we'll get rid of this. The big problem is that customers are all different and so every person is different. And so one of the challenges is that we need to try and work out the types of customers we're after. Because as businesses, we can't see every single person exactly the same way. We need to look at different types of customers, group them into segments or to target markets that we've chosen to focus on at the expense of potentially others. And then we need to understand what are their pain points? What do they need from us? Because ultimately, if we create a product that nobody wants, we may have had fun doing it, but it's absolutely pointless. So we have to start with customers as our grounding because if we don't know who our customers are, then everything else is a waste after this. So the first thing I wanted to do with this first statement is flip it around. So instead of saying, how can we bring ideation quickly to the market and then meet the customer expectation, well, how can we put our customer first? So now we'll say, how can we meet the customer's expectation by bringing an idea and a product to the market quickly? So suddenly the nature of that inquiry changes because it's not about a product first, it's now about a customer first. And we'll keep filling with this statement as we go through these six simple rules. Rule number two. And this is kind of the hard one. Now, I'm a recovery mechanical engineer and I like building stuff like anyone else. But it's really hard sometimes to stop building stuff and start listening. And so this second rule is all about listening to a customer, and it could be an internal or an external customer, and listening enough to understand what pain, point of frustration or problem that we actually try to solve before we jump to a conclusion of how we can solve it. And sometimes the cleverer we are, the harder it is to do this, to make sure we don't jump to that immediate conclusion and say, I know exactly what you mean. I can fix it for you. But we just have to listen to our customers. Because what we see is that most products fail or of the products that do fail, and then unfortunately there's a heck of a lot of them. Some of the main reasons for them is that the actual customer problem hasn't been considered well enough before the product was taken to market. Someone's come up with a cunning plan to build something, take it to market and it's gone to the market without really ever speaking to a customer and finding out why they wanted it. It's the whole story of a hammer in search of a nail. And we want to try and avoid that by baking this thinking to always think about the customer problem before we think about the solution. And often, and I've just been speaking with telcos, I think this is an example of possibly coming from a telco. I'm just guessing. But what's really interesting with many customer problems in commoditized markets which become harder and harder to complete in is it's not actually the product that people are complaining about. People don't complain, oh the product wasn't fast enough or good enough. It's usually, I had a small problem and it took me a week to get it resolved. Or I called somebody and they couldn't help me or wouldn't help me. Or there was a strange disturbance in my build and nobody could fix it. And so a lot of the things that happen to a product or to a customer's experience have very little to do with the product itself. The core thing that people are selling. So when we start thinking about customer problems it's very easy to over focus on the product that we're offering and forget about the customer experience that the customer has. So as we bring these two rules together we need to understand who our customers are and then see our products through their eyes and understand what problems they might be having. So now if we extend on this statement again how can we make the customer's expectations by bringing the idea and the product quickly to market? Now let's reframe this. How can we solve a customer problem by bringing ideation and a product quickly to market? So again we're sort of teasing out the fact that there's a problem to be solved. It's not just what their expectations are. Their expectations are that you solve a problem. So let's state it like that. If we give a product to a customer and it doesn't solve a problem well then it won't meet their expectations. Our third rule excuse me is leave the building. Now this is a concept that was made quite popular by Eric Reyes in the Lens Startup book. People know the mantra Steve Blank from Four Steps to the Epiphany or Eric Reyes who talks about it as well. This idea of leaving the building is the concept of you won't find the ideas in some you won't find customer problems by glaring out the window and hoping they'll be waving at you. I've got a problem. Can you help me? You have to get outside and talk to people. And chances are when you actually go outside and talk to people and you try and find the customers we've been talking about you'll learn stuff really really quickly. You'll learn just how embarrassingly wrong you are and as a result that learning experience once you get over the first couple you'll clarify that you're heading the wrong direction. You'll clarify that you've just saved an enormous amount of time money and resource by realizing you're heading down the wrong direction by finding that early and cheap just by talking to a handful of customers. And so the idea of leaving the building is incredibly critical but it's not just a new thing it's not something that has just come out of the recent literature in the last few years this is a concept that's been around for decades and so sometimes people put the hard word on traditional product management but traditional product management came out of proper and gamble and brand management and the whole idea of going out and meeting with your customer was established in the early 30s. So product management isn't something which is brand new and exciting the concept we're talking about here are fundamental and extend across generations across products and brands and across whatever particular methodology we're using to build the product as well. And so here's one of the tools that was used with Toyota which is a Japanese term called Genchi Genmetsu which stands for basically it's go and see for yourself and this came out, I think it returned at the 50s and was documented in the Toyota way but what's interesting with this is that the approach for the Toyota way was to get out of the building except in the case of there it wasn't get out of the building it was getting the management team to go into the factory floor and observe what was going on and it wasn't a case of just walking the floor they actually painted a yellow circle on the factory floor with two footprints in it they had to step into take their position and just watch watch and take notes they couldn't say anything they couldn't do anything they just had to observe what was happening and the solutions of getting outside the building talking to people seeing what's going on and actually getting to the place where things are happening is an incredibly powerful experience to start learning from the coal face and that's not always easy to do depending on the product or service that you're offering but if we don't try we won't find out and sometimes you need to think of strategies of how do you find your customers and talk to them once you recognise this is something that you need to do then the next challenge is you identify your own problem you then go out and find a solution ok, so we need to go out and speak with customers and again, look at this we want to solve the problem now by better understanding customers so the act of going out and just seeing customers allows us to clarify the crap that we put into our heads initially which is I think there's a customer out there with this particular problem fabulous it's a nice imagination that you've got there now let's go out and test it and so the test of actually going out with a customer going out to it and seeing a customer will validate or invalidate your idea and then send you packing back to come up with a new idea more often than not and that's still a good thing depressing sometimes, but still a very good thing so we start to understand our customers better and invariably what happens when we go out and get ourselves kicked by the customer, we learn stuff not just about what we've got wrong but other insights we draw from those experiences ok, fourth one link our actions to strategic intent often when we sort of down the coal phase working on features or functionality it's easy to lose sight of the bigger picture every organisation exists to deliver something usually to its shareholders depending on what type of business it is but also there is some strategic goal it's trying to achieve and if we forget that what that strategic goal is we can build cool stuff that doesn't help us achieve that goal so what's really important is that if we firstly to achieve those goals we need to know what they are if a business is bumbling along either without a clear goal or strategic objectives or without communicating it's almost impossible for the individuals within that team to be able to help achieve it and the impact of that is that everyone is really busy really carefully doing stuff that is often across purposes and is slowing you down and is creating more friction in the business than forward momentum so if we know what the actual goals are suddenly we can see that every effort we perform starts to move us in the same direction now and this is the joke you were wondering about earlier which is probably unique to me back when I was at university I was the captain of the Chinese International Club Dragon Boat Racing team long story look at this laugh essentially one of the things I learned by being the Dragon Boat team is that no matter what the strength of the team is if the team isn't all pulling together in one single movement the boat doesn't move forward you lose the race you've got more drag than you have forward momentum but there is something amazing that happens when the boat is moving in unison and everyone stands there under the water and pulls in exact unison the boat doesn't just move forward it surges forward and you feel that movement as a physical thing when everyone is pulling together from a business context the same thing applies everyone has the same goals and the same objectives and knows what they are striving for and achieving them with everything they do then suddenly you start to feel that surge in the business pulling you forward I was going to say something now I forgot what it was it doesn't matter it's all good so now look at this thing again we haven't really changed the intent of it we've changed the focus of it so how can we better understand our customers problems and solve it but to achieve business goals that's what it was sometimes you can feel really busy during a day you've cranked out 40 emails you've dealt with a few customer inquiries you've done some busy stuff but if it doesn't link back to the strategic intent of the business you should be able to look back at that and go huh, I just wasted a day I was really busy but I achieved nothing towards our strategic goals I was really busy I was really busy I achieved nothing towards our strategic goals and so it's good to have that little voice in the back of your head saying this thing that's urgent right now is it worth it because we're all time poor we're all crunched on time we all have exactly the same amount of time in the day and there's never enough of it so if you want to help the business help yourself and your careers then it's valuable to always be thinking is this helping our goals as a team or not, say you know what it can wait and it's probably not that important and it's probably not important to the organization we're working in okay this one will be familiar with anyone who's working in agile team and this is do less more often and it's the idea of essentially chunking things down into smaller and smaller pieces to create smaller achievable goals from so I've also run a couple of marathons and not recently I'll have to say but the only way to run a marathon is one step at a time you can't start and then finish just with one great leap it's hard work to achieve a long term goal and a marathon is a good example you can't just stumble up and turn up on the day and expect to finish it so a big project is a bit like a marathon but we have to think what are the individual steps we have to take we have to take a lot of them and also what are the individual milestones or the small milestones that we can kind of celebrate so it might be passing the 5K mark it might be getting to the halfway mark it might be things that we've achieved along the way that we can measure and see if we're on the right track now certainly the longer the project the more important the milestone and one of the things as a runner I would do is particularly in the last 30K or after the 30K mark would be that tree over there just going to get to that tree then that billboard then that bus stop then whatever was about 30 metres ahead of me just to get those little wins with each time it got a little bit harder and the same thing applies for the training for it you don't turn up the day before a marathon and run a marathon expect to survive the following week that you've reached to train for a marathon to get better at it you do a little bit on a regular basis more often you don't run a marathon every week to practice for a marathon you do a little bit all the time and so the principles of agile in particular are to try and take a bigger project and chuck it down into discrete chunks or discrete limbles that are delivering value to the customer or the market in regular chunks more often and so this concept doesn't have to just apply to agile it can apply to anything it can apply to thinking about the writing of a business case or a development plan of anything you want to do it's about trying to identify what are the smaller goals that if we achieve them are going to deliver more value because if we pick smaller goals they're easier to achieve what's the goal you achieve today what's the goal you're going to achieve this week because if we don't set a goal for this week or this day then we're guaranteed not to hit it it's quite a useful way of thinking about these smaller incremental steps that collectively build towards these larger goals the other thing that's good and this kind of combines back to the leader building one is that if we start doing things and doing market testing more frequently it means that we can make smaller bets but do them more frequently and learn quickly because it reduces our risk one of the big problems with a large waterfall or traditional type project to take a product to market is that you're putting all your eggs in one basket you're only doing a market test once which is maybe just before or just after you've actually launched a product one of the benefits of an agile type environment is that you're trying to create opportunities to market more frequently to make smaller bets with your most horrifying, scary assumption that you've made that the only way to test it is to make something and put it in front of a customer and if we're not doing that no matter what we call the methodology it's either agile or useful we're simply putting all our eggs in one basket and hoping for the best so making smaller bets that we can learn from and doing it more frequently and doing it as we go along the learnings that we get can bring us back to bring us back on course based on what we expect to be successful in the marketplace so again, looking at our original statement how can we better understand our customer problem and solve it to achieve business goals by using small, regular experiments to release a product quickly to market so we're kind of adding bits and pieces to this but the point of the small steps is to constantly test and experiment and try to remove the risk from things and we get the wins and if we don't get a win then even a loss or a failure or a learning is a win in its own right particularly if we're doing it small and the risk is pretty low of the outcome being detrimental to the organization and our last rule is show and tell which is once you've done something tell people about it with a new product idea if you want to find out whether the market likes it you're going to have to show them at some point now that could be at the launch which is pretty risky it might be during a beta test of some sort which is a little bit less risky but the earlier we can start to show and tell our ideas and express them to the marketplace and express them to the customers we're targeting the sooner we're going to find out that we're right or we're wrong and again that's valuable in this direction on a more frequent basis so if we have experiments there's no point having a thought experiment that's a starting point but ultimately we have to do the experiment so we actually have to take our ideas out to the marketplace and test them whether it's testing a marketing proposition whether it's testing a prototype whether it's testing a fully blown product or whether it's testing a technology we can call it whatever we like but ultimately we have to test our assumptions and try and find out whether they'll pass or fail the test that we could afford for the other thing is once we've tested it once we've actually shown it to the marketplace or experimented with it we get to tell people about it this is again one of the diving into agile for a moment one of the benefits of a scrum process is you get the showcase the showcase is essentially embodying this idea of showing and telling people what you did how you did it whether it worked or not and what you learned along the way and it's that opportunity to share the celebration and the success but in particular it's the opportunity to communicate to someone more than just yourself what was learned along the way and again that brings together the team it brings together that shared direction suddenly we've all learned something we don't have to learn it individually we can learn it now as a group we can suddenly realise hey I had that problem as well and you've got some information I didn't know you had so creating opportunities for a show and tell and talking about stuff and celebrating both our wins and our losses because if we use them correctly every loss is a learning experience and every learning experience is actually a win in its own way particularly if we've done it frequently with relatively low risk okay so this idea of essentially now is what a better understand our customers our customers problems solve it to achieve our business goals using smaller regular experiments to quickly test our product and get it to the market place anything we do doesn't matter until it has first contact with the market place once it's in the market even as a test we start to learn from it immediately so kind of wrapping up this little story our six simple rules our customers first problems before solutions leave the building because we don't validate anything until we step outside link our actions to our strategic intent do less more often and finally show and tell and apart from the first one which is customer first they're not really in any chronological order they weave together and overlap quite a lot but we find that by keeping these distinctly in the back of your mind no matter what activity you're performing and what part of the business you're in these I think are really powerful useful rules to follow so sometimes check ourselves so hang on a minute am I building something because it's cool because there's a customer problem I'm trying to solve if I'm doing this is it going to help move us forward or is it just some busy work that I feel compelled to do because someone asked me to do it and so each one of these rules is useful to kind of just give it a bit of a checkpoint not to massively change our behaviour but to sometimes redirect and create more value from the work that we're doing on a day-to-day basis so we've transitioned this kind of this starting question from how can we bring the ideation quickly to market to meet the customer expectation of the product to which is really quite business centric like we've got an idea we know everything why won't the customers like it to let's understand our customers let's listen to them let's understand their problem then we'll find a solution to it we'll make sure that solution satisfies the business objectives that we're trying to achieve otherwise it's probably going to be important if there's anything we need to test let's go and test it test it with the marketplace in a cheap safe or low risk experiment and then be prepared to take that to the marketplace and tell people about it later on that's my little summary of our six simple rules for product manager so I'd like to throw it to you guys and see if you have any questions about the showing of our product yes a lot of times you can't tell what your product is when you're product is used to the market you know there are other individuals so how do you if that that mid chunk is gone how effective do you think the product is going to be because we can't probably show it to the product I think the the fear of exposing your product to the market before anyone else sees it I think is an overbuilt risk and ends up being a bit of an excuse not to expose it to the market now it doesn't mean that you start putting banners and flags up saying we've got this idea and come on competitors come and see what we're doing you can still be quite discreet about if you choose to be but I think that if you look at the the fear of a competitor following you and copying what you're doing means that they have to catch up to you to where you are in the first place it assumes they care about what you're doing and has part of their strategic intent to copy what you're doing but more importantly you need to trade that off against the risk of not knowing whether you're right and so if you keep going saying I don't want to show anyone I don't want to show anyone and wait for the big bang launch and then you go ta-da and nobody comes to your party that's going to be a bigger cost in most cases than the risk that you're in the marketplace going that's cool let's copy that does that so I think if you can make small experiments they're not necessarily showing everything but to try and find out what are the things you don't know about yet that you need to test and framing them in that context you're doing experiments, you're not doing market orgies necessarily yeah so nil doesn't actually build products for the market we build it for the market but our customers and other people who pay us are companies who themselves need to launch the product so framing the six rules in that context our customer being another business since we're in consultancy where does the product manager's role fit into driving these six rules in every direction I think regardless of where it fits into the overall flow when a product gets built we need to know by the entire business even if it's an outsourced public business when you kind of trend this as the family or the end of the process of I've got an idea too, it got launched whether that function is in-house or external the question of the asking of the question is who are we building this for if you're given a brief and it says make this thing that goes ding and I'm sure that's never happened just in that context before then you should be questioning or challenging or trying to avoid the response of I'd really like to know who your target customers are so they'll understand when it goes ding, how is it going to please them what are they trying to do when it goes ding should it go ding at all what problem are we trying to solve with this because the way most people think they think in terms of a solution they incorporate their thinking of the customer and the problem it's not that they haven't thought about it but it's become internalised it's often not expressed so your clients potentially might be coming up with an idea and by the time you get to it it's a solution concept, here make this okay and the thinking around the customer and the problem it's trying to solve is a couple of documents away or it's been scribbled on a napkin or it's just internalised in the business in the minds of people in the business so by asking these questions they're relatively non-confrontational they're common sense questions that for anyone in that whole process should be asking the question before I can do this effectively I need to know who we're building this for what's your target market can you describe this person or persona to me so that we can do it and what is the specific problem we're trying to solve because unfortunately usually the people who come up with the the big idea and describe it as a solution have no idea how to build solutions they've got an idea which is valid in the marketplace they've seen a pain point and they've imagined their solution to the problem but they don't know how to express or they don't even know what's possible in terms of other alternatives so as part of that value chain creation within an organisation I would say think about these rules and think about how you can extract the information that supports them as you're developing products and services for your clients and ultimately for their customers we'll take a little discussion do you have a question? you were saying you can find this you know just write and write you try to understand the rules the solution there's a similar principle here it's easy for someone to give you a statement of works and treat you like a speciality you deliver on that but what you've lost the opportunity to do is actually helping the customer to find the correct statement of work for someone that's deduced from the solution and perhaps if something will be developed you'll deliver on the scope and then they'll realise it doesn't actually quite work and then they might prefer it so you can add a lot of value by first helping them understand that it really is scope the right kind of thing they shouldn't really be thinking in terms of what's the solution of the like that you really need to be articulating what their problem is because you are the developers and sometimes you need to guide the customer to do that because it's a very unnatural general for someone to try to describe the problem they have normally they might not be able to describe the solution they think they need I'm sure you're saying it's actually the act of describing a customer problem is very specific and often to make it a valuable product the problem has to be quite painful it has to be quite uncomfortable in the customer's life otherwise if it's not painful or uncomfortable why would I spend money to get a result there's not some clearly articulated frustration like oh it's driving me nuts then why would I bother changing product to another alternative the example that's kind of ringing in my head these days and I've seen it in different countries already is Uber Uber I think is a really good example of a product solving the same problem but in a different way because it tackles the key frustrations of getting a cab in a city they haven't solved the cab problem they haven't solved the traffic problem you still get in a car with some stranger you then ferry it around to the place you've got to get to you're still stuck in traffic watching the meter rack up but that's not the problem they tried to solve they tried to solve the problem of where the hell's the car where's the taxi what number do I call look at those other problems outside the core problem of getting a point at point B and because if you think through the tick list of all the things that drive you crazy about getting a cab and then look at the Uber product you'll see crossover taxi, crossing taxi tick Uber, tick Uber and that's how they create their product differentiation it's not because they have better cars or more comfortable seats or nicer drivers there's a little bit of it but that's not their differentiator their differentiator is the pain points of frustrations of customers probably wouldn't even have said they didn't like about the taxi process because they're just putting up with it and sometimes the process of understanding customer problems is kind of putting a bit of a jabber into those customer frustrations and really exposing them realising just how frustrated with stuff they've learned to put up with in life and so for a client to be able to articulate their customers problems reflects a real deep understanding of their customers and their customers problems that they probably don't have so it can be a bit of a conflict sometimes tell me what your customer problems are well they don't have to get a cab, don't they and that might be what you get and you have to dig deeper to try and find out how you think being a cab alternative is a much better option the other questions or comments or discussion can you talk a little bit about the difference between working with like an early stage startup versus a company like Centella or you know bigger organisations like how that changes the way that you work on well I think they've both got their garnages and disadvantages so an early stage startup everyone's got some skin in the game everyone's working a small team and you're ability to communicate with each other and like a drag and boat team go like a team if you imagine a drag and boat instead of having 20 people on it has 2,000 people on it and getting them all to work in unison wow that's a tougher problem to have and so you end up with silos and people with sort of varying KPIs that don't seem to marry up with other KPIs and all of a sudden they're trying to do different things and go in different directions so trying to have really clear goals that everybody shares that is relevant to everybody in the business becomes much much harder in a small organisation you can say see that number on the wall we need to make that one number go up come on team let's help around and make it happen so that's certainly one aspect another aspect is that when you have a larger organisation you don't just have one product you actually have a pipeline of products that are in different stages of maturity decline and introduction to marketplace usually in an early stage start-up organisation you've got just one product that you're trying to get firstly out the door then you're trying to get product market fit then you're trying to get growth of that product and you have the opportunity to be quite focused on it to do that it doesn't make it easy but you've got all your attention to focus on just that one thing I think that's probably some of the key differences you've got far less bureaucracy and red tape and if something's not working in a small small team it's up to the team to fix it if something's not working in a large organisation it requires a very bold person to swim upstream and say stop this is a box it doesn't work and we need to change it and that's not really the case in a small team so what are the advantages of a large team you said four times with being a large organisation in a small team I've heard the advantages of a small organisation in a small team but advantages of a large team well one of the advantages is if you make a mistake you survive and so the people who are in those roles probably don't need to be as motivated it doesn't mean they're not motivated but if things go wrong and a product doesn't turn out the way they want it to it's like whatever and so they can get lazy particularly if the organisation is doing pretty well and that's where you can see organisations like Kodak or Inokia that have been chugging along doing really really well for a long time and then suddenly the market moves as they're disrupted technology and customers suddenly start doing something completely different and they don't change their directory they're too slow to move to either create those things and they die and it can happen to any size organisation because those organisations can get lazy in terms of their desire to change with the marketplace but I mean that's obviously two examples which are at this advantage the larger organisations they have fat they can survive a couple of body blows if they can take it and it means to create the body from a quality of life perspective and it gives some of the employers really like that but then they have to deal with the soloing, the back fighting the apologics that's it, there's different sizes of each one It's an interesting conflict we have because we work with startups and also large companies I guess large companies will have more money but then they're more at worst sometimes to be doing virtual testing because they have this big vision that's justified internally and it's gone through all these different departments that's it we've got funding sorry, just build it we don't want to do any validation or testing or anything smaller like startups five person team or something they want to minimise risk but they're much more budget conscious so they see the value in it but they just don't have the money to spend on it because we're consultants we work with timing materials and if you just have any questions, do you want to build software or do you want to test whether you're doing the right software being a safe build software because it's so someday right and part of what we do is try and diplomatically alert them to the fact that maybe it's not the right approach but we also don't necessarily want to talk to ourselves about business too so it's like this really conflicting sort of, you quite kind um you know maybe you're second in the market maybe you need to find a market that is big enough to be able to afford the value you offer but it's also got a bit of a cultural element and you can go to an example that you've sampled me like there's a cultural mismatch and I think it's easy to just call large enterprises the same okay? they're all cheap in November and they're still plenty of newer and more successful organizations who have become quite large and have a tolerance for our job approaches to developing things and business development and quite a lot of activities to try and see it as a way to assess some kind of fine-way detail of a fine-way way of second in the market so that you can better seek out those organizations that are buying you know I think also in both cases it's easy to just look at this as one business behaving one way and another business behaving another way for instance there are a bunch of people and people are screwed up and scared at the best of times and so in a large organization someone who's just been through three different sign-offs just to get you employed just to get a deal signed with you and then you say oh by the way could we test this which could invalidate all the work you've just done to get to this point and maybe we'll lose the job anyway it's like do we have to? at this point do I really have to test this and so the fear that testing might actually expose the fact that the original idea was wrong is horrifying and that's a human condition it doesn't matter what the organization is and the same applies in the startup the startup are kind of thinking well I've quit my job I've maxed out my credit card I really want this software I believe in it and I'd rather not find that out right now I'd rather wait till I'm really screwed to find that one and that's really kind of the difference in both cases there's this horrible fear of being wrong and not trying to accept the possibility that it might be you could be wrong and just kind of putting your hand in your heart and just believing in yourself and hoping that will get you through and so the the challenge is to try to recognize that and to tease out that small bit of the scariest bit and say how about we just do a little test and what's the smallest test we can do to start trying to validate or invalidate or not invalidate but redirect possibly the type of inquiry or question or product we're offering here because it will save you the angst later on if I took if I took a modern market as a junior and the buyers junior basically says this that modern buyers today will engage the supplier not to sell the junior so to sort of think about yourself you might want to buy a video now a lot of people these days want to start with the shop and ask questions that will go online research the option and understand what it is they might actually need blogs that might be this, that might be that and that's interesting so they'll consume content that talks about problems and they may associate themselves with those problems and then look for a viable solution and then only get to the point about the option then they'll choose channels in the market or a gallery way maybe at that stage there's a sense of sweeping assumptions you might be contacted at that point and while they're contacting you they'll try to figure it out but they've already been through quite a lot of them so empathising with mixed scenario first they almost died going through a process and really going through a process of evaluating compliance defending or compiling and defending the business has secured funds so if there was a possibility that you could present your brand much earlier whilst they're at this stage now then you need to solve big problems in your organisation before you buy off a massive chunk of 3-2 years of your life looking at cases perhaps if you can see positioning at the start you could have a chance to influence them well before they go through business that's quite an aspiration I don't know how you go apart from them but if you did that then you would get in the world our objectives and sales organisations influence the tenders before the time they come down the tenders really is just a human process influence what they need prior so by the time they come to market they're already evaluating the need and the correct amount so by the time the shop comes on the scene it's already gone for a lot of the processes that they've been sort of talking about and this is again kind of smiling back to the six weeks of ruins in your direct customer relationship this is where you need to understand your customers so if you're simply saying okay we're a development resource we're quite software development people so give me the brief hold we'll get busy with it then you're not really understanding your customer they're giving you the solution they want to have solved but you're not just understanding the other problems that they are having to just get to the point of where we're at and so by understanding your customer and understanding that in any context in the description we're using here the customer who has gone through the individuals, not the business the individual buyers who are trying to bring you on board what have they had to go through they've had to go through a sign-up they've had to go through maybe a tender evaluation or just playing off one or two other things they've had to secure funding if you can do, if you kind of think about your business development process how far up that chain do I need to help influence people what doesn't I do to influence them before, well before they have to fill in a business case then you're starting to understand your customer's needs and you're providing a solution not to just the development problem but to the business case of writing a problem to the how do I get sign-up problem to the how do I justify that I should be testing this before I build something problem okay and so again you only find that stuff out by going out and speaking with them and you guys how do you actually get sign-up because I'd like to be able to help you with that eventually but I need to understand it in the first place and so again these simple rules can be applied in the same way internally not just to your clients clients and their perspective so that's what I US offices are doing a lot more of like validation projects and and I think the US is more open to that and what maybe simple is different but that's exactly what we're just talking about them going into the early stages validating the idea coming up with different ideas seeing where they can innovate before there's any actual brief of building software if software is the right solution yeah but I think this idea is really powerful though because by the time the customer has gone through the bias journey they've got a human mind it's almost as if you poisoned the well but you've influenced the customer you've influenced the customer's journey which now that you've put the idea in my head I see so many organizations already doing you know with the land awareness and with people putting up blogs and directing traffic to the blogs to become an authoritative expert so they've been a big person, goes through the stretches in journey of it and the time that they've gone through the whole thing whenever they go to the shop they're asking questions they're asking you the questions which you have framed for them and that you already have the answers to you know it's almost like they're ready to buy for you it's interesting, I like that I think I've already Southern Victor brain there are perverse modes so we're trying to get it to a player before they've made a decision about what they want because you can see your points of differentiation when I've seen it in ways that some organizations will see certain capability or language or brains early on so that by the time they know they know that's something that's a mandatory requirement then no one wants to not have it because it's actually a term of that time that it moves from the point of view of the brain so I don't know if you came up with the ability of sitting in order to to use to use to use to use to use it's a silly example but you've got that opportunity that you need to know how to I don't know this one since the 90's and they quite possibly are still trying to do it in the enterprise market where they would frame a business problem in terms of the solutions that they provide and they just blast the market with it that was the strategy for squeezing out people like Linux and the Netscape and the rest of all of the the coach market strategies they had I can see them having done that so the people would ask an active directory solution for them Microsoft is the guy with the active directory and so they had to go there and they squeezed Netscape out of the directory so Netscape no value but squeeze the directory business with the active directory thing and a lot of other technologies were similarly which you have mentioned it's interesting I agree that understanding that has to be a problem is very important but you also mentioned that I agree there are many things that are very different so are there frameworks that we can use to better understand like sometimes the customer don't even know what their real problem is but it's actually a problem but we just need to help them with the structure thinking that will help them identify the problem is that they understand it's not made to be flippant but the shortest cut solution is talking to them there's no magic wand that is any better than just talking to people and so it starts off as being one conversation and the other aspect of it is you're talking to them and you're listening to them you're not selling to them you're not trying to pitch to them you're not saying I know the solution you need here it is, bang you're simply listening to them and you're using what we use to use other simple questions to other simple questions to probe a customer's answer and I simply use the question why, based on using the 5 why's to get to a root cause problem but also to say so what so if someone says I've got this problem I say so what and it's meant to be a little bit aggressive to get and say well hang on the reason I have this problem is because the impact of this problem had this situation then I start losing money I lose customers and boom and you start to get a response but if you have a problem that has no impact then it has no value it's just like it's an irritation you can do without but if people start expressing their problem in terms of the impact or the cost of a particular problem you start to get a sense of it what's the cost if you're late to work if you're saying oh yeah I really I get to try it a bit of drag who cares and if I ask you what's the cost of that to you for some people it don't matter some people might be I just missed a business meeting which means I didn't get the deal which means I didn't get the raise which means I lost my job getting to work on time is pretty important that was the impact with very high that situation so the combination of those two questions why, why, why, why but quite like that we've been talking as well and asking for each one of those so what, or what's the impact you can soften the word if you like but those questions I find very, very quickly start to open up the conversation with the customer to explore the problem that they're trying to solve it's still, why, why why, why it's 5 y's so what's something that frustrates you why are you wearing a jumper why is it cold why is the hair come to you does everybody else is cold why is it when I'm cold I don't know because they don't really get the multiple cold to me so it's not that 5 y's is asking why it's just, yeah so the principle is why, why, why it's more like chilling down on the floor doing some root calls why are we doing questions a lot, a lot of the the game used to be there were kids like this they'd be asking questions like why you forget the first question and so you you still need to listen, you can't just throw it why isn't it, they're really quite powerful to start to open up the potential problem so a classic, almost a joke is the classic Henry Ford quote of, if Henry Ford means to say that customers don't know what they're talking about they don't speak to customers because they don't know what they want so the Henry Ford quote essentially says if I asked customers what they wanted they would have asked for a faster horse it's almost cliche, it's used so often but it's used as a reason not to talk to customers but I think it's a really good example of exactly why it's talked to customers because I would say that customers said I want a faster horse they've imagined their version of a solution but I don't know what their problem is and I said well why do you want a faster horse I don't know you said you want a faster horse and depending on who they are they'll have a different answer if they're a doctor they might say three times this week I've only just been able to help my patient because currently the horse I have is too slow okay, so the time it takes you to get from one place to another is too slow why and then we've got all this baggage and stuff I have to carry you start to learn a little bit more about the situation that customer is in what's the impact if you're late well people die and I'm no longer having good reputation as a doctor so I'll lose my job it's a pretty serious implication and so you can start to tic-tac between those questions and understand a little bit more about the customer and understand what their pain points are and what I found it might sound silly I'm going to now refer to Sesame Street there's actually a great little skip on Sesame Street talking about the word of the day is Hypothesis and Journal and what that's doing on Sesame Street I'm not quite sure but it's pretty awesome and it's a section on essentially teaching kids the scientific method and they do exactly this, they ask why so their hypothesis is that everyone on Sesame Street has a bath so the first customer you see is some guy in a bath with the property of the taste bubble because it's a kids show and yes, tic on the Journal this person is having a bath the next character they come across is a bird rolling around in the dirt clearly getting dirtier and so the scientist who's trying to disprove everything is haha, I have an ante or an invalidation of our claim and then the bird says no, hang on, I am having a bath I'm a bird, I have a dirt bath and so again by asking these questions and trying to learn things directly from the marketplace not only do they either validate or invalidate each claim they go through these different variations of different bars on Sesame Street but they learn that in this case their claim was true that everyone on Sesame Street had a bath but what they really learned which is valuable stuff was that everyone took a bath differently so Oscar the Grouch is having a mug bath the bird is having a dirt bath someone is having a real bath so all these variants come up but the value of, if you want to get fast learning you can pour through data analytics lots of stuff and you'll find the information there but you won't find the deeper insights that are happening on the other side of the screen and so it's when you actually speak to people to see what people are doing and you can actually get those wow moments this sounds to me a little bit I just have to look it up I've read a book quite a while called Spin Selling which is about a sales technique and I don't know if you know about it the process sounds similar to the sort of program that you do to actually get to the customer's pain you expose the pain and you can properly propose a solution for it yep absolutely it's exactly the same and so the approach we're talking about is the objection handling except in the case of a salesperson they've got a thing they're trying to sell so they're trying to find an edge way in ah there's a problem I could hit boom I've got a solution for you from the product management perspective our starting point should be I have no solution otherwise we're just a salesperson not the sense of wrong with it but the product development and product management thinking is the market place without a solution yet because I could just make something and hope for the best thank you thank you I could just go out and make something and then try and sell it and then I'm trying to overcome objections but if I pre-empt that if I actually make something based on the pain points that I've explored and extracted from the market place and then I go to the market and go tada I've kind of shortcut the objection handling entirely because now I've created a perfect fit for the market place based on the objections I've already taken out of the picture and so you're right it's exactly the same technique except now we're kind of pre-empting that by developing the right product in the first place rather than trying to convince someone to buy a product that they don't want it at all I was part of a new methodology called shop pansies when I talked to a lot of people in our projects one main problem I faced was that when you once you get an initial idea you start working and actually you go and test your product you always find a mix of people there's some people who like your product some people don't sometimes there might be more people who don't like your product but at least few people who like your product but at what point do you need to decide that you know maybe the people who don't like your product out there that few people actually like your product and it's time for us to change or is it but for every product I didn't go on to test you'll never find one or two people who like your product and it's often common for people to get you know get them a vision and say okay this guy likes my product so obviously there's going to be a market for this one you just kind of go on in his life if you are on the guidance on what's the movement of how do you decide or anything on those things where they know that or when they're on the right path quite a couple of answers to that firstly if you're asking customers do you like your product they'll probably say yes because they like you and they don't want to upset you so it may not be the way you actually frame it on the day but if you're asking customers do I like it then chances are they'll be nice to you and say yes they'll help you achieve your goal and so part of that understanding of your customers is understanding what their goals are and part of our definition of a problem is anything that's stopping me from achieving my goal or slowing me down to creating friction so if you present a product to somebody and they use it and it helps them achieve their goal better they might say I don't like the shading you've got there on the whatever it is but yeah it was pretty good you're hitting the right direction so I think framing what you're trying to validate is actually really important if you say do you like this design and they say no I hate it you've probably found out that they don't like your design but it doesn't mean they like you as a product when Craig says it's a really good example of a product that's ugly as hell yet it's cheap and does a job really well for a very large market they couldn't care less what it looks like because it does a job this is where most people are leaving because they don't want to test what color it is or how shiny it looks so you want to keep it as low as possible so people don't really comment on visuals or the shape of color or something like that so for me early kind of prototype testing is less about an opinion and more about stopwatch it's about hey you've got a task to do if you like if you you've sick of that person because they're likely to be doing their task show me how you use this interface whether it's a piece of paper a powerful deck or a fully interactive prototype show me how you achieve that goal go and if they start working through it and then I'll potentially compare that to another alternative if they go through it faster and achieve their objective didn't feel stupid, felt good at the end of it then it's going to be a better outcome don't care if they liked it if they get their job done you worry about like versus not like the very last stages of it because if anything it helps I don't like Uber I think their management and their approach of data policy is awful what I think about getting a cab I think cab queue I think you know what I'm going to weigh it up bring card to me and it's because it solves a better problem in the marketplace than it is so there's this tool the hypothesis statement and so we believe that by doing this thing we will solve this problem and we will know if we achieve success when we reach this KPI go something like that and that's the way to look at everything we do like even on the story level all these principles can be applied to individual stories it's like who's it for what problems are solving normally or a lot of the time it's just an assumption it's like let's just do this we're doing some story but to understand why who the problem is for and what it's solving that can be used in anything even writing a document or an efficient statement or anything all these principles it doesn't have to be a really top level product idea it is it fills right through to every sort of daily task some of these principles are used today a number of times I think a user story is a really good example because quite often user stories get written more as a feature story not as a user story I'd say you haven't met the user you can't write a user story you're bad so people who write a user story without actually having met the customer had real information from a customer it's just made up stuff it doesn't make it wrong but it certainly doesn't make it right the customer makes it right and so customer first problem for solution is what a user story is all about leave the building find out whether you're in fantasy land or real world by testing your assumption around the user story link your actions to the strategic intent if you have a user story that you think well that's interesting but it's not going to help the business then it probably shouldn't be on the backlog or it should be lower in the backlog than other user stories do less more often or the idea of having stories that are relatively small so you can do them more regularly and of course ultimately show and tell don't just show the rest of the team show the user that you thought was the core of the user story and get them to validate that the outcome the definition of done has been achieved if there's going to be acceptance criteria it's their acceptance that should be the criteria of the user story in addition to any technical or regulatory or any other sort of internal requirements that's necessary that's all I have a ton of questions I think you probably need to wrap it up cool if you want to stay in touch with us here's different ways of connecting with us certainly follow us on Twitter and if nothing else follow the hashtag product management PROD, MGMT to get all your product management improvements but pull up bravites anyway did you guys make that tag? it took a while the product management filled up 140 characters straight away and it's a PROD MKTG I think that's the product cool thank you very much