Guest Frances Smyth

Dave: Hello, and welcome to the podcast. I’m your host Dave Albert. In the show, I talk about technology, building a company as a CTO and co founder and have guests to discuss their roles in technology and entrepreneurship.

Today we’re joined by Frances Smyth, agile coach at Claim Vantage, MBA candidate at TCT and a speaker at the ollie conference. Thanks so much for joining us for Fran.

Frances: Thank you for having me, Dave.

Dave: It’s a pleasure. So can you tell us a little bit about you know, your background yourself and what you do?

Frances: Sure, sure. Well, I am currently an agile coach. My title just recently changed. I was a scrum master before then when, you know, needing to change my title or anything like that I have only done that recently. But essentially, I’ve been acting as an agile coach up until this point, but in the past I’ve done as a scrum master. And like a lot of people, I sort of fell into this when my company at the time adopted Scrum and roll that out internally. And it really just clicked with me and I said, this, this is what I’ve been wanting to do. And this is where. this is the answer, the answer to everything. And I had been interested in project management before that, and it never really went anywhere because I didn’t fully buy into it that, you know, you could plan that far out ahead and then just execute on a pre pre organized plan and end up at the right destination. I think there’s there’s trouble with that. It’s never going to go very well, and you need an adaptive method like agile or one of the agile methodologies and frameworks to work within our to have some sort of a hybrid mix and match between the two is my current thinking. So my, my current, I’m always expanding my, my understanding of everything and right now I’m actually taking an MBA course. And that’s opened a new doors as well for me. So my thinking of my thoughts continually go and in waves, waves of creation of ideas, and then destruction of those ideas when they don’t really 02:40. So I’m learning every day, every single day. And right now I’m working on, I’m actually just working with a small medium enterprise. And they claim to have adopted agile a couple years ago, didn’t really do anything. They they went through the motions and, you know, we made a number of changes since I got there. So that’s pretty good start suddenly.

Dave: If it’s kind of a lean approach to your own thought processes, I guess that’s what it sounds like hypothesis, test, learn, adapt.

Frances: Probably is and that’s probably why it costs for me so much. You know, I never feel like I have the right answer to anything because of that. So I only know what I know today and what I believe today with that can change if new information comes up.

Dave: But I like to say, one of the worst programmers I’ve ever seen is myself six months ago, and I think that every six months, so if you haven’t grown to think that you your past self was uninformed, then you haven’t grown enough yourself.

Frances: That is the best way of putting it that I’ve ever heard I’d be a lot meaner to myself.

Dave: And maybe a little too mean to myself, but

Frances: Yeah, exactly.

Dave: Yeah, that’s it. Go ahead. Go ahead, sorry

Frances: Um Yeah, I mean, you can, you can only really know what you know today and no one person can know everything. So we can only try out what we can see. And I mean, Scrum itself is only really been out there since 2001. And only really in Ireland been adopted in the last number of years. And as, a on a general scale. So, you know, it’s something that is relatively new to everybody and the thing the work that it was originally defined to do, we’re kind of picking and at that, and we’re making it we’re trying to make it to do to, to work in other areas that it wasn’t originally intended to do not, write anyway. It was originally constraint to software and over the years have been has been expanded out into other areas like marketing and or even our sales team is using Kanban and now they don’t they haven’t been told that it’s called Kanban, but they’re using one button. So As soon as you start telling people the words for things, they tend to think, Oh, I’m getting confused, or you need to learn a new thing. So, you know, it’s a lot of people are kind of the crux of everything aren’t they.

Dave: Absolutely.To what, what type of teams, what size teams do you normally work with?

Frances: So my teams are quite small, actually, I have, I like to say five at the moment, and, and they’re quite small. So four of them are actually facing our customers. And they are our services teams, professional services, and one is our r&d team. So they’re working on the core product itself and trying to upgrade all of the functionality within that, while also balancing or customer demands and our customer asks as well. So they’ve got their own set of problems and the professional services side has their own set of problems. So it kind of depends on the set of people that are involved the work that’s involved, and then they interplay between all of those things.

Dave: Okay. Um, yeah. So what I was what I was wondering, is we know how, when is this team not ready to learn to be more formally agile? Does that question make sense?

Frances: I have had and still have teams that aren’t ready to be teams. They are all teams. And so when I actually first started in my company, we had about 16 developers and everybody was working individually and they, you know, a developer, you like to get your head down, you write your couple of classes, you cover methods and you you get out the door at the end of the day and you don’t tend to have want to talk much to other people unless somebody’s got an issue. So it’s very individual, and especially when you get more senior developers as well who can work I’ve done and can take that initiative on their own. So, it to me it’d be less around what in a team who isn’t ready to be agile, I think I’ve seen little resistance from anyone to being a job or to, for people to understand what they’re doing, why they’re doing it, and then also to work as a team. Those three pieces, I mean, we tend to do two of them, we tend to roll out scroll in particular, we wrote the methodology, the values, and put getting people to work as a team and to want to work as a team, I think is much more difficult than getting them to want to adopt something that’s going to make their lives easier.

Dave: Sure, yeah. I mean, I you know, you’ve got to get the the purpose and the internal motivations, nothing people to move forward.

Frances: Yeah, yeah, exactly. Yeah. And it’s difficult, it’s not often easy to see that people aren’t behaving as a team. And I don’t know if you know the difference between a team and just a group of people. So what would be originally had when we set up our team is where really just groups people who were, who were assigned to the same customers and the same code basis, but they didn’t read until very recently, and this is a year later, it took that long, didn’t really work together, they help each other but they didn’t feel like they had supported each other, per se, or that they need needed that support. And, and it actually took something along the lines of a crisis, a good crisis, but um, you know, a lot of pressure and a lot of tension of it that situation or in a new customer to make them work to do that.

Dave: How can you accelerate the the formation of the the team bond within the group of people other than a crisis?

Frances: I haven’t seen a way to do so I think if you’re starting from a situation where people have other come from teams are used to working in teams are used to working in Scrum teams in particular, they’ve seen it on or they’ve, they’ve experienced it before, I think it’s a little bit easier for people to understand. But if you’ve got people who have and engineers who have maybe wanted to or have to work alone for an awful long time, and you know, the only interaction with somebody else was when you were working on a similar piece of area of the code, or something similar to that, or you needed to redo refactor somebody else’s code. And they’re the only real point at which the engineers that I worked with had really overlapped in the areas that they needed to do their work in. When we came to doing their teamwork, splitting up the tasks as well wasn’t something that was, you know, natural to them. It wasn’t something that they’d ever had to do before or even even being asked to do before. So, trying to help people understand what that was about and why they should do it was extremely difficult actually. So this is why I think the the keep will keep saying as well let the people are kind of the hardest part of really anything and especially rolling it or any new system or new structure new and new methodologies like, like Scrum and Agile. So we actually even in a small company like mine, when I joined my company, it was only 30 or 32 people or something like that, and we’re eighty six now two years later, which is kind of a good growth for them because they spent 12 years just with the same number of people essentially. And you have to undo 12 years worth of habits that have been built up by not having teams not having, you know, someone else to call upon, and not having the volume of people that you get in a medium or large company. So you’re working within those constraints where everybody just had to get their own piece of the pie done. And whenever needed doing have to get done. So switching all of that out, and switching people to working in a different, a different way of working and breaking those habits took that long of a time. So I think it’d be got the buy in and you’ve got the understanding of what teamwork is and why you would do it and why it is necessary and why it will help you actually do your job and help the company. You know, be able to process more tickets or whatever it is. That you’re trying to do. You can build things, you can move more things, you can move faster things, and you can build them in a better way by working together like that. So trying to change habits of sitting in a room, we literally had whatever meeting rooms was actually a closet. And it was it was also our server room. Age. So I think if anybody is working in a startup, you would also have that understanding it’s it was start opening with startup for about 10-12 years. So we’re only really in that on the uptake of the hockey stick and it’s starting to take off now. And so in the time that I came in, they were still in that crossover point between startup and investing in the number of people that would be required to grow but also waiting for that growth to actually appear. So planning for growth and being ready for growth and then actually having the people ready for that growth as well, was quite a difficult balancing act to maintain. And this is something that I think a lot of companies will go through I think it’s I’d like to say it’s almost easier if you’re making a product that nobody outside of the company really has much of a say in like you do have customers who have a say here are going to buy it, who are going to be purchases of your product. But at the startup stage, you’re reacting to that you take in all of the requests, you you try and create, you try and execute as many of those as you possibly can to create the product that can sell to the most amount of people. Then you reach the stage. My particular companies that and you realize that you’ve built a Frankenstein product over the years. Stock point in you know, in Agile, you’ve got this person, you’ve got your product owner, they own the product and it own we’re going where it’s going There is none of that there is no stop way. So my own personal take on it is, if you are, if you are going to have agile in your company, start off, agile, because it will make things easier for you when you get to the stage that we’re at.

Dave: Yeah, you know, that’s something that I’ve tried all along to find the right flow for our team. When you’re starting with a product, though, if your users are extremely conservative, like doctors who are our core audience, it’s very hard to put out a product that does not have a good usable set of polished features. And we’ve we’ve consistently tried to figure out the right way to do it. So even trying to work agile in an agile fashion, we’re still obviously, there’s a large amount of work that goes into that first release version. Any insights on how someone might avoid the mistakes we’ve made in the past that maybe we’ll make again, hopefully?

Frances: Yeah, I hear you. So yeah, you’re you’re kind of talking about the iterative release process that agile has we actually haven’t been able to replicate that I’m in a similarly restrictive industry of the insurance industry. You can’t go wrong, people want it if you got it wrong. So we have to bit and they don’t want a partial product as well. Yep, that’s difficult that we have. And what we can do and what we do is we will release a beta version. And that’s available for testing for user acceptance for anything like that. All of those good things and that generally pointed out missing pieces of the puzzle that we might have or missing piece of the functionality that we might have, generally now we’ve been able to say, you know, we’ve got three quarters of it done and we’ll add it in our next release the final pieces that you need and be workarounds let’s say, so we’ll get a lot of it through legislation, particularly US legislation. And, and that is notoriously difficult to codify you, they, it’s written by people and it’s written by humans who are trying to understand the situation and provide for all all eventualities and they really don’t and the first round of a piece of legislation, and yet our companies and our insurance companies are expected to support that legislation. So we have a similar dilemma in a parallel industry and are are really. And once we had a core offering the additions that our core offering ended up being much smaller pieces of the puzzle. But they didn’t make it less complicated. So it was always a little bit frantic. We spent one year I think, working on Ad New York paid family leave, we spent a good year on that and put the legislation took a good nine months to write. So we are coding and they were writing the legislation at the same time and walk by the business. So they didn’t consult us as well. They have no reason to consultants they have to have a consultation through our customers. And they would contact the states and they would contact the federal government and get that information for us. So it was even more difficult. And that’s something that we continue to experience going forward. And it is it ended up being quite a scramble at the end. But I think in industries like this, I don’t think it’s entirely possible to, to predict those who plan for things like that. And that is really, agile comes in handy. We were able to build it as we’re going and make modifications as we’re going. So people could test various parts of the product. And I’m half convinced we actually helped build that legislation because we were finding gaps in the logic and and passing that back to our customers. You probably pass it back to the legislation writers.

Dave: Very nice. Oh, so having the similar problems that we do with being needing to build out fully functional fully fleshed out polished products. How are how do you handle estimates of how long it will take to build something so that your, you know, your sales team and your marketing team can, can be there in the ready. So that, you know, you can’t just launch a product and have users or customers immediately you have to plan for it, you have to prep for it, you have to put in the effort and that effort often needs to be close to execution. Because if you’re writing copy for something, the circumstances will have changed in a month’s time that different copy is going to be required. So to avoid other teams that are non software development or product creation, how can they be prepared at the right timings? Do you have any insight into that?

Frances: We we almost we’re we’re getting now a little bit backwards to how you would do it. You’re you’re getting the influx of recording are essentially the sales people and marketing people saying I can sell your product if this was in it. And this tended to be how our product was built on how it was sold over the years and how it reached critical mass. And I, my own take on it is we would see things that we thought should be in the product. And we were really tested out at a user group. So there’s actually a yearly and we’re probably moving to twice yearly user group with our largest customers. And that’s already when you have a large customer. You don’t have that base, I think you have to rely on the balancing act between the existing customers, keeping them happy, keep them their business running, and the generation of new business. So balancing those two aspects of product design think were a product owner really comes in very handy to manage that. And and they will be the one who everybody on board, sales marketing, CEO, everybody will be bombarding that person saying, Can I get this in the product? When can I get it? And they’ll give you a one liner, you know, this piece of functionality, so many needs that are the big user base that needs it. Let’s get it done and make it happen. And that’s tends to be how products are built in young companies. It’s early market driven, because of equal with an idea that nobody wants to buy, then, you know, you shouldn’t really build that or it be a big chance to build it as well? User generation of ideas, crowd based input is really helpful. And not always but it it is helpful for generation of ideas that are actually saleable. And because of course, in a small business, you’re going to have to, you know, balance of every step you make with in a cost benefit analysis, raise your gut feeling even. There’s got to be some sort of balancing act versus the effort that it would take to actually implement something so that one person for nine months is 10’s of thousands of dollars. You know, it’s a lot of investment and if it doesn’t work out, or no new company wants to buy your product because of it, and it’s the reason you’re doing it is to maintain your existing customers. It’s gotta be worth it.

Dave: Yeah, okay. That makes sense. Well, so, let’s say you’re coming in to be our agile coach at my team. What are what are our first few steps, one of the first things that we need to do together,

Frances: Good lord. I interview people, I almost interview people. I would ask every single detail about your company about the current way things are doing the current people that are there. How do you have any things tend to get done today. And I’m really trying to plot a path to a better way of doing things. And every move that I think any company needs to make it really, really, in particular small companies you can afford a mistake is to adjust very slightly rather than the Big Bang Theory of throwing things out there and changing in one day. I think it’s a very slow process compared to that. We don’t have the, you know, the money, you know, the people, you know, it’s, you know, you can’t stop work. A lot of these things require you to spend a week or two or three, we’re just learning about the process and trying to trying it out. And I know a lot of companies and a lot of workplaces can actually do that. So it’s a bit unfeasible for below a certain level of company, I think for a lot of people that get things done first. My first question to you would be then what is your tolerance for not getting things done for a long for, for how long? How long can you afford not to get things done for..

Dave: Zero? It seems like everything is already taking us longer than any of us would like.

Frances: Yes. And that’s the other thing about estimates their estimates are not actualities that our reality, when you need to modify something along the way, that adds to the estimate that adds more time more review time, maybe you gotta retested, you gotta send it out in front of people again. So the iterative nature doesn’t, doesn’t always whittle down and and funnel to a perfect product. It can remain at a certain stage of the process. And there’s a couple of different methodology that I’ve started branching out into. There’s a methodology called jobs to be done. That’s actually Google, you’re probably familiar with it. Yeah. And there’s another one from the School of thinking which is design thinking and design sprint. They are building a whole product or feature or product in a week. And I had recently the pleasure of attending we’re spending a few days doing that as well. And it was really interesting, and I don’t think there’s an ideal product but I think there’s a good enough product to go to market with. I think spending the time to get something polished and perfect and then have it not sell is also a troubling point at which one can get stuck. Oh, you know if you can get something to 80% of that is that somebody will buy. Why not just built 80% and this is really from the front end, it’s to stop any design, the design sprint, are really around stopping you getting stuck going around in circles and trying to decide what kind of flowed have and where to place a button on the screen? I mean, it doesn’t really matter that much. It makes a slight difference. Doesn’t shouldn’t maybe have meetings about it for a month, which is, you know, I’ve seen happen in the past.

Dave: Yeah. There’s gonna be a couple of points where I end up silent as I’m trying to digest what you’re saying. So I’m using this as a free consultation as much as to record the episode.

Frances: I’ll send you my bill. I thought you were bored to be honest, so we need to I love my subject and I I am actually quite agnostic about using just one I don’t think there’s one tool for the job. I think there’s many tools for the job. And there is a reason to have waterfall there’s a there’s a reason to have agile, there’s a reason to how design thinking and it’s picking the right tool for the right job, I think is really important thing to do. And I don’t think there’s anyone methods that you should use, I think we should be using maybe a mix of methods. And then to really suit the environment as well. You got to see the environment, you got to see the company you got to see the people, you want to see the process, you know, the process is the process. It’s just, it’s just a process. It’s just something to help everybody do their job. And if it doesn’t help you do your job faster than job it like why would you do it?

Dave: Yes. That’s what we’re, you know, we have a limited number of people, we have users with high standards. We have, you know, concerns around delivering something not up to standards of our core users of doctors. We can’t really sorry, go ahead.

Frances: I’ve seen doctors scheduling software on their computers and I’ve seen their computers and since it’s stuck in the 90s for the most part here in Ireland anyway..

Dave: That’s true, but they they use those through requirements of either the hospitals or the practices they’re working on. Our product is for their personal use on their own personal funds. So the chances of them putting up with something that looks like something that they would have to use for scheduling is less than zero.

Frances: Actually is this you should look into design Sprint’s because I sounds like certainly you’d like them because the last day of the sprint is where you show it to potential customers or potential buyers, or existing customers and they will walk you through what they like or don’t like about it and then the next day you edit it and change it again. And all of this is done in a prototyping fashion where you don’t actually build any of the software but you get the look and feel right

Dave: Yeah, that’s I’m I’m familiar with the sprint book, the Jake Knapp. I we have not actually done one. I would love to of course, we have to have all the people in the room for the entire week. What are needed and that’s one of the challenges that we have is you know our CEO, Julie, she is the closest to what a product owner should be. Within our group, though she has consulting work that she has to do, which is keeping us afloat as we’re bootstrapped mostly. So we do not get her full time, unfortunately, and it would be a terrible thing not to have her in the room for that full week. So as much as I want to do on we’re going to have to, to wait until we’ve gotten a bit more momentum to do it but absolutely cannot wait to do that. You know, especially as we want to begin iterating on the product and and trying different elements as opposed to the way that they have not, they’ve changed, but not super drastically from some of the things that we got through our first user interviews. A couple of years ago, actually. Now, there’s been a lot of small iteration changes, but core changes, like what I would like to see us do in a design sprint, we haven’t. We haven’t released enough yet to actually justify that. So that’s, you know, we’re constantly trying to help ourselves move faster. And really, the only thing that I can do is continue to try to remove waste. Unless there’s something else that I’m missing.

Frances: Taught me through your process. What What do you do right now? How do you find out what your new features should be? And how do you find them and how do you move them through?

Dave: Yeah, so big thing is, you know, say, Julie knows our users because that was her job before was, a head of global digital marketing of pharmaceutical company. And so her job was to sell to doctors.

Frances: Yeah, you see my currency was a salesperson for our major competitor and so I can do it better so I actually had to de invite him to our design sprint because he he’s sales. Oh, he just wants to sell a product. And he wants all of the features in it. Every single feature you can possibly think of, because he’s a salesperson and he doesn’t want to tell anybody that a feature doesn’t exist in their product. So you can kind of get stuck a little bit with billing too many things. And that is one thing I kind of warn you guys about is we we did it already. So I would like to warn other people to not do it is and bills go down too many paths. We put ourselves down a lot of pots now and we’re paying for that debt. We’re paying that debt day now, not even the way our product was designed, but in how it was executed, how we got our ideas in and, and where they came from. And the vetting process for those ideas, vetting them against actual potential customers because I like that a customer will also tell you I want more features. When really do they so the jobs to be done it kind of gets that scales up back, what do you actually do? And the jobs to be done methodology is probably a really good one to take their to figure out what you need to do over what, like you could potentially do. I joined my company there two years ago, and they had 10,000 JIRA tickets open. And I said even really gonna do all of those things. Can we close a few and they were so resistant and people were like, are very resistant to saying, we’re not going to do something. I said, we’ve got, like 10 people now at the time, and we’re never going to get through 10,000 tickets and we get a bunch of them every day. Pick a pick a road, we need to pick a road to go down and stick to that road or, you know, stick near that road. And the very, not trying to all the highways at words.

Dave: Yeah, sure. No, it’s it. So we, as part of the NDRC accelerator program, one of the big sections of it was based around some jobs to be done. And we use that while we were defining what the product would be. You know, we’ve got our section for content discovery, we’ve got sections for content sharing, which is our collections. We have the peer to peer communications, which is our groups which we’re still in the process of finalizing, which should be out in the next week. Along with our Android version finally. So it’s not that we’re adding on additional large chunks. It’s as we begin to you. So you know, we did a bunch of testing of groups or within our team. And it was quite obvious quite quickly, that we had a few falls in the way we thought it should work. That, you know, until it was built enough to us, it was really hard to realize just how, how annoying some of the things that we thought were necessary were not. And I don’t know how we would have known that until we had actually interacted with it. So I, you know, I’m not saying anything necessarily good or bad about that, but it just it’s one of those things that I just wish I knew how to only work on the right things and do those faster as opposed to everybody else.

Frances: There’s no magic, there’s no magic bullet. I think that’s the learning curve. And that is, you know, that’s part of why your competitive advantage, isn’t it that you spent the time and the money to go through that learning curve. So, you know, you can’t really get around a lot of it, I think. And we’ve had some similar issues where I currently work again, so around, you know, how do you build something that we don’t know what it looks like, at the end? We’ve never seen one of these things before. So we’ve had similar things with them. You know, how, how the trying to build an ERD when your customer doesn’t know what an ERD is or anything like that, you know that it holds together. But once this is set in stone, in our particular industry, we actually work in, we work based off Salesforce, and that’s quite restrictive. So once you actually have a design in place, you’re stuck with that design forever. You can Yeah, so once that made it to the, to the framework to the managed package as it’s called in Salesforce, you can actually change that that structure.

Dave: What’s an ERD?

Frances: An enterprise relationship diagram. I’m sorry, I shouldn’t use jargon.

Dave: No, it’s fine to learn it. I just want to make sure that everybody knows what it is. And there are so many acronyms in the different industries, I remember, Fran and I worked together at Symantec, my first week or two at Symantec, I heard so many different acronyms. I wasn’t sure if I was not as smart as I thought I was because I didn’t know all the acronyms in in the industry, or if they were semantic acronyms, and it was half and half.

Frances: Are those that was a distinctive learning curve. I think there was this cheat sheet full pages of acronyms.

Dave: There was, there was a.. I think it was a team site page. It does not even, so that was an older wiki style document one on the way. It wasn’t Confluence. That’s That’s all I can say.

Frances: Yeah, it was bad. It was like a really old SharePoint from.

Dave: SharePoint. That’s what it was. It was a SharePoint.

Frances: Horrible system.

Dave: Anyway..

Frances: Don’t build on of those anyway.. That’s all I can say.

Dave: Sorry, you were saying so, if you’re going to build an ERD, and they don’t know what that is..

Frances: Yeah, I mean, you you’re talking about building a product and you don’t really know how to put it together and they’re not in both level, like you don’t you know what the functionality is, but you don’t you’re not a medical professional, you don’t work in all industry. So, you know, you don’t know what they do every day in their job, and sometimes other people will just tell you what they’ve seen before as well, so getting people to use a product in a new way, or a new way of using product, you know, remember when the the iPod came out, and it just had no buttons on it, it had a real one button. And everybody’s kind of going, what the hell is that? You know, but it’s amazing and it was groundbreaking technology. But once people used it, they found it wasn’t that scary at all. It wasn’t a huge learning curve. So minimizing the learning curve, I think, is probably the best thing to do in this day and age. Because instead of walking people through a process, especially when you first sign up to a site, you know, instead of walking them through the process, the process should be so simple and intuitive that they know how to use it anyway, you know if they’ve never seen it before, but they still know how to use it.

Dave: Yeah, that was one of the first things that we changed from the initial designs was our signup flow. Because we realized that we’ve made it too hard. You know, we thought about our needs, first of all the elements that would make it easier to serve the user and didn’t think enough about how, you know, the user is already curious enough to want to try to use the app. But if we keep putting barriers in front of them that we’re going to keep losing them. So we iterated that process. And that was that was great.

Frances: Yeah, I mean, you see that with, I think it was Dropbox, they had the same thing where they had like a sign of model sign a business model, where they gave the, you know, certain percentage away for free. And then for everything else, you have this you have to pay for it. So the majority of the user basis is X amount of people who aren’t paying, but the ones who are getting value from it or the business users, then the 2% that actually pay the money, they’re the ones that actually pay for almost everybody else, but you need the other 98% to generate the interest in the platform and the usage of the platform, and the sharing from the platform. So people couldn’t would share Dropbox links with me years ago. And I couldn’t open them because I wasn’t a member Dropbox. So, you know, you have to be a member. And then once you shared from that, from Dropbox, you would go and you would sign up to become a member, but you aren’t going to pay money, just wanted to get the link that somebody sent you. So it’s thinking really, really understanding customers and the people who use it on the psychology behind it, I think is a really big deal. And because it causes you more work or any work at all, actually, that feels like work to open an app or to share something or to you know, not be able to share something then that’s something that you know, people don’t like because it’s not seamlessly integrated into your life that there’s no separation really between work and life. And it’s not a work life balance anymore. It’s a work like integration, especially for professionals like medical professionals.

Dave: Exactly.

Frances: Yeah, I think understanding that about your customers, I think in particular, your customers will be those kind of people who don’t switch off who don’t, who like to learn all the time who need all of the information on needed all at their fingertips, so and whatever way you can do when your product to provide that I think is probably where they’d like to see your product heading in a general sense.

Dave: Yeah, no, absolutely. That’s 100% agree. And we do actually have conversations like that about will this make it easier is adding, adding this extra element will make it a little easier to understand, in some ways, but does it add more over mental overhead that just isn’t worth it? So, you know, we’re always weighing those things out. And I think we do a pretty good job of that. Still doesn’t make us move faster.

Frances: We get back from our original conversation that I know we were kind of this is what I’m talking about with my take on things and what I’m learning every day is you can’t really pick out that putting in this process is a good solution to solve all your problems and making people think of a team is going to solve all the problems. It’s not as kind of a combination of everything. It’s a holistic view of the whole ecosystem. That’s the really difficult part. And I don’t think that’s being created yet. I think when people have done it successfully, they don’t want part of it really successfully. So like Apple like that, they took their product and they made it excellent, essentially, and their sales people sold it excellently. And if you if you subscribe to that, and they did and what they’ve done other things that weren’t so excellent and things like you’d see this in Amazon, for example. So they put out a lot of products, not a really successful things for the part you don’t really hear about or the really own successful things. They spend a lot of time experimenting and putting things out in the wild. Seeing if it works seeing more conscious think that’s quite quite the new way of doing it. It’s called an adhocracy.

Dave: No, I haven’t I like that.

Frances: Yeah. So part of their part of their company organization is a bit of an adhocracy, they create teams so Scrum, you’ve got stable teams you’ve got the Serum, Serum point five their one feature and that stay static because if you change a team from management thinking you’d be changing team you’ve got a form and storm and normal perform all over again. So if you change any one of those variables, by traditional thinking, you have to kind of start all over again. In adhocracy, you take people with particular skills and what multi talented skill so you can have a project manager who can also develop or, you know, overlapping skills, I guess is a better word for that. And they form project teams and they will be the ones who sees an opportunity. So in agile, you’re organized around and you’re organize around excellent, I guess I’m producing a product as fast as possible. But it’s also got to be slightly well, you kind of you lose a little excellence when you go for speed. So it’s balancing those three things speed, an excellent on all after agiles. And if you go on organize your teams around opportunities, there’s a it’s just a different take on things. And this has no real methodology around and it’s not, you’re not sticking to anyone methodology you can use waterfall with it. But it’s just waterfall is used in terms of having a high level plan, you know, you’ve got to build this product, you know, you’ve got to build X amount of features. You got to get those features together and then pick where you’re stopping point is. And you know, after your project plan, you’ve got your team, your QA and all kind of fun stuff to go through. You know, kind of in general, everybody knows in general what your project looks like but the details, they can move and they can change. So you still kind of work on a little bit agile. We’re not releasing anything until the very end of the project, which could be a couple of months. So you can still work in, in small sprint, or you can work in waterfall methodology. But either way to people on your team are agile to the people on the team, just make sure that they get a bunch of stuff done every single day. And you’re all moving towards the same goal. Just one of the fundamental reasons that you are a team everybody can see the end everybody’s invested in it. And they actually all have stock I believe in Amazon and that’s one of the reasons people are so so into Amazon and so enthusiastic and a little bit coltish. But you know, they they are, what it is with it. So they form these teams around the market opportunity or business opportunity or some kind of targeting. We need to build a product to sell for this problem. Let’s go try to do it in a really fast time frame. And if we fail, we’ll just forget about it and move on. Because we did it really fast. It didn’t work out, people are going to pick it up or not, you know. And you can find a quick whether you failed or not, whatever the product has, you know, stickiness, it’s going to stick in a market where people are going to take it up. So I think they haven’t Amazon mobile at one stage. And when people are talking about Amazon, they’re excellence. They don’t mention all the failures. They just mentioned the successes. So learning about how to fail and how to fail fast as a really good way to do it. And rather than had a wind fast, because I think even if we built the most excellent product, and you could still fail. So how do you do that as fast as possible? That’s the real question.

Dave: That’s really good. I know I’m going to listen to this episode. number of times. It’s a lot to take in there.

Frances: This keeps me up at night this I good lord.

Dave: Well definitely love to have you back. If you if you find this enjoyable.

Frances:I do I could talk for days on this is where I could talk for days.

Dave: I could talk to you about it.

Frances: Yeah, I mean, there’s so many different options. I guess it’s just try one and see which one works. Try them all.

Dave: Let’s, you know, we keep trying, because nothing is perfect. We just try to keep making the smaller changes that keep moving us forward further and further. But, you know, if you’ve got high standards and want to be great, but you also want to move fast. You know, it’s that triangle. Good. Good, fast, cheap. startups, unfortunately don’t have extra money laying around.

Frances: This is it. It’s that. I mean, that’s the reason that I actually just finished a course on entrepreneurship and really, what you want to do is create the most valuable product with the most features for the least amount of money and that’s how you win.

Dave: Yeah, that’s exactly what I was saying. I can’t remember who I was saying it to. But just that, you know, we need to figure out how we can ship more value faster. That’s what I really mean by faster, don’t necessarily mean more, more lines of code, more more features, just more value.

Frances: Yeah. Well, if you had to have your, your consumers of the product actually rate which features were most useful to them? Would that be illuminating? I bet it would.

Dave: We’ll see, I think, I think groups which required a load of work up to this point, as a foundation, so the foundation was necessary so that groups can be built on top of it. I think groups will be one of the things that brings a great deal of value to people but I think held in their hands. That’s speculation, I suppose. But it’s it’s based on user interviews and user understanding. It’s not based on you know, looking your finger and sticking it up in the air to see which one way the winds blowing. It still has to be released so.

Frances: Yeah, yeah. Yeah, I mean that’s the investment and that’s the piece of the puzzle that’s extremely difficult part heavy stay afloat while all of that is happening. And you you know, you got to get to that stage where you have the foundations built and I can be years as well. Before you can build a really good stuff that makes the product take off so people don’t see all the sweat and tears that went into the background of it. They just see the finished product and think it was look that got them there. I think that you know, the, the apple example. I don’t know how many years they put into research around this, but it could have been 10 years of work and 10 years of millions and millions of dollars for all you know which should explain the price of an iPhone.

Dave: Tell me about it.

Frances: It would put because it brings us such value you’re going to, you’re going to pay the most tolerable limits and probably beyond it to get that value. I know I do.

Dave: So what you’re you’re thought going to be about at the at ALI. That’s the Agile lean Ireland conference on the 26th of April. Croke Park here in Dublin, Ireland.

Frances: I ended up just attending this year actually. Yeah, unfortunately. But it is a two day event this year. So I’m really looking forward to that. And really just seeing what kind of knowledge I can come out with it. And from there, you know, with and bring it back to my company into the people or interact with So, you know, I’m always looking for new pieces of information. I think getting stuck on one methodology is probably a bad idea. I think getting I don’t think anybody’s got the right answer. I think they found the right answer for them. One of the things everybody wants to do is just copy what somebody else did in their company. And, and, and, you know, re re engineer that in their own place and have the same success and results from it. But it doesn’t quite work that way. Because the other company has a, as a cause of ambiguity, you don’t really know what caused their success. It’s not simply agile, it never really is just simply doing one thing. It’s always a bunch of other things and on picking what the defining factor was. That’s the difficulty everybody has today. There’s also like a path dependency. So the decisions you make today will affect what happens in 10 years from now. And there’s nothing you can really do but that but also at the same time, it makes it harder to imitate your product, because the troubles and trials and tribulations you’re going through now are what are going to make your product successful, essentially, they’re going to be non the immutable not imitated.

Dave: Yeah, good. Because even if they copy what you’ve done at this point, they don’t know what you know, for what comes next.

Frances: Exactly. Because you don’t release your failings. You release your successful products, you receive all the successful things you did. And you might have refactor things. And you might have made learnings along the way. They can’t re engineer that you count backwards engineer process, you count backwards engineer, engineer, the things that got you to success. I don’t think it’s possible now at this point in time to do that. And I think it’s, and there are some things you can avoid. It’s like learning how to ride a bike, you can avoid toppling over at some point. You can never just read a book and say, I’ll replicate that and go out and do it. You have to, you have to go through the process. So let me just have to go through the process.

Dave: Nice and apologies is the 25th of April and the 26. So that’s a Thursday and Friday. I got confused by the, by the banner on your LinkedIn, I didn’t see the 2018. So sorry about that. No, no problem at all. I missed out on a good speaker, but at least you get the opportunity to just listen and learn this year so.

Frances: Exactly. Yeah, I found it very difficult to do both well..

Dave: I’m sure I’m sure you were you were thinking about your talk all the way up into until it and then an adrenaline dump afterwards.

Frances: You know what though, I wrote that presentation on I was still editing it the same day because things are still changing. I was trying to explain at that particular presentation that point in time, what we done and what we change them how we don’t it, how we are the steps we taken to change minds internally. So changing minds is is much more harder than changing processes. And kind of leaning towards now, changing team minds. And then as a if you picture like the team level as a circle and then an encompassing circle would be the the managers of those team members or the functional heads or somebody else project managers or whatever that you might have in your company, and a third level and from that is all your sales people in your business people in your support people and your CEO. And all three levels kind of need to be thinking along the same lines, and often aren’t. So the values and the mission statement, it’s such an old phrase to say for it for a company or product. It’s where are you all heading? Are you all thinking about the same things and same ways to get there. And by that, I mean kind of if you’re building a product and you you’re building and then you have a vision already in your head, you skeleton, have an idea what this product should look like and perhaps what it should feel like. And your business people in sales will have a different idea of what that should look and feel like and then your end users will also have a turd idea of what that looks and feels like. So getting all of that line is kind of important, I think.

Dave: And how how to go about that through those user days and the design sprints and things like that, or are there other techniques that you can recommend.

Frances: And I think agile is one of the team based ways of doing that. So when you run a scrum process, you’re rolling out a change process, essentially, you’re rolling out something not get everybody on the same page. And it doesn’t do it on its own because when you make decisions about a product and where to go with that product, you kind of need to know where the CEO wants the company going and where they want the product going. And and then also help the sales people understand where that is going as well. So the way your product looks today, externally is completely different from what it looks like internally because you’ve probably got some adjustments and modifications enhancements already in the running. And, and then three months and six months from now, it’s a completely different product again. So how do you keep all of those things together? One of the things that you can do is you know it’s scrum, you’ve all got a really good understanding and a vision of where the product is going. And that’s what your product owner does. There the person who’s supposed to figure excuse me cough actually. I don’t usually talk this much. I lost my voice in my first couple of months at this at this company, actually because I never spoken so much in my life from rolling in values and making sure people are on the same page, on the desk, on the phone. So yeah, it’s it’s, you’re rolling that out your product owner provides you with a vision of where the product is going, both at the level of a sprint, be at one week, two week, three weeks or whatever they tell you what kind of feature what you’re kind of working towards, and then also how longer term vision for that product. But all of that they kind of need to get that CEO in line and make sure the CEO knows what they’re selling. You know, they’re going in there, there may be going to conferences or, and you know, the right places where you’re going to find your customers. That’s where the CEO ends up going and doing all the press associated with so they should have a fairly good idea of what your where your product is going. The harder part is getting that idea out of them and onto paper in a succinct form that everyone can make the same decision. So you’ll see this in case studies like Southwest Airlines and even Amazon actually they are have their 10 volumes and principles that they work towards. So they are relentlessly working on behalf of the customer to make the customers lives better. And then they, they actually also have them what’s called it, the 10 principles are actually stuck portable theater. So if you need to make a decision, anyone at the company level of the company can make a decision, because it will relate the one of the values so, and I think the column leadership principles actually. So they have this customer obsession, and you know, everyone’s a leader in my company. And what does that mean? That you are, you know, you got to be right and that you’re always learning and that you’re insisting on the highest standards and now you’re also thinking big at the same time. But if you have to weigh up one against the other, that that’s actually an ordering system as well. So yes, the customers forest and the SE gotta think big. But if If thinking big combs does it come before after the highest standard? So there’s your excellence a year, you’re weighing up against? Do I need this at 100%? Or do I need it, you know, do any more features. So that’s the scope and time variable so that you can juggle, but everybody in the company, then a guideline to work towards. So if you need to make a decision, you don’t need to wait for the CEO to make the decision because everyone can, can make a decision and can make an educated guess, about what, what the CEO wants, because the CEO would have been involved in having these principles laid out. So you all know what those principles are and what those rules of engagement you can call them, or then everybody should be able to make a decision based on hose rules. So here’s where our product is going. Here’s where companies going, here’s where our product is going. And here are the rules that we’re all going to follow and are going affect every single decision that we make because you know, cost, they’re going to be involved in these decisions as well. So if you do want to satisfy the customer, but at the same time, and you want to keep excellent up there, you want to help the most things. And but you also want to simplify things, you know. So how do you how do you juggle all those things, put them down and write them and see which one comes above the other. And it will be a terribly difficult exercise, but I imagine, but once you’ve got them down, that will be the foundation for success. I think.

Dave: That’s Yeah, I’m definitely coming back to listen to this again.

Frances: This is I’m giving you an MBA and go.. you guys.

Dave: Yeah, definitely want to have your back.

Frances: Yeah.

Dave: Since we’ve already already done this. It’s already been an hour. Can you believe That?

Frances: Yeah, well, yeah.

Dave: Feels like we just sat down. Well, um, before we wrap up, what? What would you ask anyone in the audience to do? What should they do?

Frances: I would ask them to really just think about the system holistically. It’s not one thing, it’s not one technique. It’s not one process. And it’s not only one framework, you one thing doesn’t change the whole system. But one thing will change that part of the system, which will then enable you to change another part of the system. We’ve got to work on the whole thing. I think it’s really important.

Dave: Nice. And that that sounds like what our UX guy has been actually advocating within the build of the product.

Frances: Oh Lord, promote that man.

Dave: So it’s not even about the processes. It’s about making sure that holistically every change we made is integrated within the entire product. So yeah, no, absolutely. He’s. He’s fantastic. And as is everyone on our team..

Frances: Yeah, yeah. How far is nailing down your your leaders? Because salespeople do not want to pick one path and stick to it, they want to sell everything. So you’re probably a problem are going to be people.

Dave: Definitely. How can people reach you?

Frances: You can reach out to me on LinkedIn and I am all over the place on social media. So any channel that you find me on feel free to reach out to me, okay. And agile coach will probably be next to my name and just click those buttons if you need to message me or ask me any questions. I’m very willing to help, I love to help others.

Dave: Awesome. I’ll add all your links into the Show Notes. And thank you so much for joining us. This has been a pleasure.

Frances: Thank you Dave. I was it was really pleasurable for me to have somebody listen to me for an hour.

Dave: And thank you all for listening.

Until next time remember any sufficiently advanced technology is indistinguishable from magic.