I’m about half development, half UX for various tedious reasons and I’ve spent most of the last ten years playing around in the Agile world, niche interests, trying to get Agile development teams and Agile product teams and user experience folk to play nice together and have both of those play nice with the business so that they are building the right thing.
Todd: So, you are here at Agile 2013 and you ran a session on Lean startup and business model Canvas type stuff.
Yes, I was trying to get people to think more about the search for a business model as that, a search rather than an idea fully formed from the forehead of Zeus. I’ve spent a lot of time in my carrier working with old school startups, went through the first .com boom and I’ve seen many, many people fail because they have this one idea and they work it up and spend all their time getting funding for it, building something big and large and then launch it to the world as this glorious thing and then it fails miserably. And then they tweak it slightly and it fails miserably again and they try to spend a bit more money on it and they spend a little more marketing and they put adverts in the tube and it still fails because it’s an awful product that no one wants and moving away from that has been a wonderful thing over more recent years as the Lean startup stuff becomes more common knowledge as the more ethnographic user experience type skills become more valued in companies, you’re actually seeing people going out, talking to the customers, understanding their problems more deeply and making little steps of progress towards the product and the market that they are going to build for and people having a lot more success with that. So that was what I was trying to help people move towards and understand in that session.
Todd: Maybe explain to us how or why is that important here at the Agile conference and why should they care about that.
People should care at the Agile conference because it fits really well with the Agile value of continual improvement and meeting customer need rather than spending a lot of time with documentation and process and that sort of thing. Most Agile methods, we rely on this oracle of the customer teams or the product owner or whatever to provide us with the things we should be building. They are the ones that are saying this feature has value to the company, go away, implement it and all will be good. And at the end of the sprint, when we have built our feature, passes all the acceptance tests and the product owner says “yes, that’s what I wanted you to build, thank you very much”, that’s the classification of success for the Agile team, we've done what we were asked to do. The problem is we relatively rarely look a step further than that to see does what we built actually do what the business wanted it to do in the end? Does it make more money for the business, does it get more customers, do we make those customers happier? That is kind of outside the scope of the Agile development process, is all the product owner’s responsibility or the customer teams responsibility or the product management teams or whoever is doing the product portfolio. And because of that we lose opportunities for learning, we spend our time building things nobody uses, we can’t use the feedback we can get from delivering to customers or from talking to customers before we build stuff to make sure that the stuff we are building is better and correct, and while I get a huge buzz out of building software that’s of good quality, I get even a bigger buzz out of building software of great quality that people use and love and I want other people to have that buzz.
2. From your workshop, what kind of response do you get, what are people learning from that?
I think that the thing they are learning most right now is the idea of approaching your product and approaching your business as a series of questions and hypothesis rather than ideas that you want to implement and then sell. If you are approaching your business or products with the idea you might be wrong, with the very strong understanding of the way you think your business works, the way you think your product is going to work and be accepted and used, our assumptions are not facts about the world until you’ve actually proved them in some way, you might think you know the customer really well, you might think you understand exactly how they are going to use your products, but you will nearly always discover once you have that product in their hands, they will be using it in slightly different ways and they will value slightly different things about it and there will be this other customer from the corner who really likes this for some other reason and they might be a bigger market and you should be building for them rather than the original customer. All those things you can’t understand without closing the loop from the original assumptions you have through to building something that can test those assumptions through putting it out to the world to verify that those things are true. So, it’s closing that loop, it’s having the idea, the assumption that you test rather than making the decision up front, we don’t like doing in the software building process, we shouldn’t like doing it in the deciding what to build stage either, we need to close the feedback loop from the original idea of the product right through to the people that are using it and getting that learning back to building a better product at the end of it.
Todd: One of the tools you use in the session is Alexander Osterwalder’s Business Model Canvas, which focuses on the business model of the organization. In most organizations, particularly in the development team, people don’t necessarily know what the business model is.
And that’s a huge problem because it means that they can’t deal with change in an effective way without going back to talk to people that do understand the business model. If you are building a feature to meet some specific need and maybe you need to split the stories or you need to thin it, unless you understand the real reason why you are building that feature, the business reason why you are building that feature. You can sometimes thin it in the wrong way and that’s something I see quite a bit, the original product idea that’s out there in the business meets a certain need and then you design a feature to meet that need and then you ask the team to build that feature, but the user story talks about what the customer wants rather than the thing the business wants because the customer wants that and then the actual implementation is slightly different because you don’t have time, you have to thin the story or for whatever reason and the changes that you make to meet that which the dev team understands it and it’s happy, the product owner might understand it and be happy because it has become disassociated from that original business need, you end up building something that doesn’t meet it.
In a few different ways. I’m hoping that people start using the idea of the hypothesis as a communication tool that runs throughout the whole company, it’s one of the reasons I’ve become attached to the Lean startup model in the last few years, the idea of the hypothesis and the experiment is something that you can use right at the start of product discovery, it’s something you can use at a very strategic level, within using the Business Model Canvas around the whole business model, around your initial contacts with customers before you’re really building product and got product market fit, but it’s also the concept you can use during development, is something like are we building the right thing?
What is the smallest thing we can deliver so we can prove this hypothesis. It’s something we can use after development, when you’ve got the product out there and you are collecting numbers from usage statistics where you are doing less development-y things, like split testing and stuff like that, it’s a common model that you can use throughout the whole development process, it’s something you can use to get alignment from everyone from the business side right through development through to operations and support and customer support, so that’s a very powerful tool, you’re not translating from the product owner who is or the product manager who feed the product owner are usually put in the position of taking the original idea that they want to implement then translating it into another artifact, the user stories and things like that.
Now you’ve got a much more commonality model throughout the entire process and that is very powerful. The other powerful thing is just trying to bring more people with those skill sets together in one place, rather than having the development team separate from the business and the more generative end of user experience folk. Having those people working together, having business people and developers and designers all working at the same time on the same project, in iterations that don’t just cover the development phase, but also cover the product discovery and business model side of it, as well as the actual implementing the product side of it.
Todd: You mentioned how the UX and the product owner and the product team and the development team working together on that, so a lot of teams will say that’s the product owner’s job, they can work with the UX people and then just feed it to us when it’s ready, but you’ve been involved with a lot of the Lean UX stuff which changes that approach, so maybe describe us a bit how that approach is different.
I think that approach is different because of that it’s not my job thing. I think if you looked back at, to pick an example from the development world, pre-Agile, pre-XP, testing was somebody else’s job, that was the QA department’s job, they did all the testing, all the hard work, proving that what was built is what you wanted to build, and XP and all the lightweight Agile processes started showing once you brought things like test driven development into the team, once you started doing away or changing separate QA departments and you had embedded testers on the team, you suddenly saw huge productivity boost because test driven design meant that QA wouldn’t have to deal with the idiotic failures that automated testing caught which meant that they could spend their time on hard testing problems, they could focus on the difficult things and I see a similar thing when you start onboarding and integrating business and design people onto the team, it starts removing those extra stages of mistakes when you uplift the knowledge of the whole team a little bit, when everyone knows a bit more about design and everyone knows a bit more about the whole business, while someone else has the specialty, when someone else is the leader in that area in the team, there is the person you go to on automated testing, the person you go to about testing, the person you go to with design questions, the person you go to with business questions, but they don’t own that area, they don’t own all the business decisions and they don’t own all the design decisions, they are just the person you go to if you’re unsure about something.
Once you’ve uplift all the knowledge of the team in those areas a little bit, the whole team stops making dumb mistakes which wastes the experts’ time to fix, the designer doesn’t have to continually go and tweak bits of the visual design because there is a framework, because there is a structure, because the development team understand the basics, the basic laws and rules of heuristics, of visual design, they are not designers, but they don’t make the dumb mistakes that someone without any design knowledge makes. Once you have that level of competency, you can just make progress faster and more quickly because you don’t have to spend your time documenting the details or correcting all the little nickels, you can user lighter weight artifacts, you can communicate by talking to people rather than exchanging wire frames and full Photoshop comps or whatever.
And the same applies to the business, if you’ve got the business people involved everyone understands more about the business value that people are trying to achieve which means that everyone can use their knowledge and their expertise to get to the place the business wants to get, if figuring out where the business wants to get is just someone’s responsibility then they can’t leverage those other skills from development and UX and that’s the thing that empowers those teams so much, that they can work together much, much more effectively in the same way that Agile development teams have brought all the knowledge that you need to do development into the team, now Lean UX and balance teams are bringing all the knowledge you need to discover, build and deliver a product into the team.
Todd's full question: Many people say they look at UX and to them UX means the person who does graphic design and Photoshop, they do wire frames and then they have to get approved, they get Photoshop mockups that need to be approved before they can even get started, and they might say I don’t have those skills and you talk about picking up some of those skills, a) how does that workflow change in a Lean UX world and b) what sort of skills should a developer be looking to pick up when they are not necessarily a graphic artist?
I think it changes in a bunch of ways. Part of the reason that designers do things like wire frames is to communicate the results of the work they have done to understand the product that’s being built at a more conceptual level, you’ve gone out to look at a group of users and you see how they model the world and understand how things work together and the concepts of their use and then you use those concepts that you’ve discovered to design an interface that is easy for those people to understand and then you deliver the wire frame of that interface as it were to the people to build it. Now the problem there is that the concepts you’ve discovered over here aren’t in the pretty picture, they’re in the designer’s head that made the pretty picture, so it’s much more effective for the designer to talk to the team and start communicating those concepts directly, maybe as well as having the wire frame, but often you don’t need that level of detail anymore, you can start sketching stuff, you can have much lighter weight artifacts and a lot of the communication happens directly with the team, sometimes that stuff goes directly into code.
To pick one example, we had a client some time ago who had a very complicated form-based system and it was a fairly big redesign which wasn’t particularly Lean at all, but once we finished with it, it had a very happy path through this process, usually it was a route to the next page, it was a button that took you through this path and then there were little digression that went off the happy path depending on meeting some needs, getting a document from somewhere else and that sort of stuff. And that was very important to this, the workflow that was used by people that were on telesales insurance type environment, so it was a high turnover, it had to be pretty simple to learn and use. Now, after that redesign, we could have just - the existing development team had a template system, had a little MVC framework, we could have just given it to them and they could implement it and no problem.
The problem with doing that is in the code there is no concept of this happy path, in the pretty picture there is no concept of that happy path, so what we did was, in conversation with the developers, we explained why we were doing this and why it was important and showed them from user tests and making them more involved in what was happening when we were building the requirements, that this was an important factor and that made people extend that state transition system that was underlying this form system to include the concept of the happy path in the code and the concept of the happy path and the automated acceptance test and the unit tests and the way that the display layer was built, it was a web-based system, so they had IDs on the buttons for the happy path to force there to be only one on the page, so those in turn were backed by automated test.
And so if someone later on accidentally added more than one happy path the tests would fail, all the key concepts the design folk had got from talking to the users and understanding the problem and domain were also in the code. One of my sayings that I throw at people all the time is a product should be beautiful all the way down and a lot of time in user experience it’s only beautiful as far as the user interface, as far as the mockups that were produced by the design people, but because you don’t communicate the concepts well, the code does what the interface does, it doesn’t have the concepts underlying it and so it’s implemented very differently and sometimes it’s like you’ve got the outer body of a Porsche and it’s got three moped engines underneath making it work. Once you have the whole team understanding all the concepts, you have to produce far less artifacts and the product reflects the problem it’s trying to solve at the code level as well as the user interface level, which means as the product evolves over time, you get far less problematical change, you don’t have the same maintenance problems you do before because your code is reflecting the problem domain more.
I think the biggest and most important skill and often the hardest one for people who wear the introverted developer hat, which is definitely a hat that I wear and I have worn with great style in the past is going out and actually talking to users, talking to customers and interacting with them. One of the simplest ways you can start doing that is with user testing, getting people in to use your product, in Agile teams I would really recommend trying to do that in a regular cadence that goes along with the iteration or if you’re in a Scrum-y thing, every couple of weeks, something like that and just get a few people in, you can talk to your sales people, you can talk to your customer support people, maybe technical authors as well, but the people who know more about the user base to figure out the kind of people to get in and then there is a great book by Steve Krug called Rocket Surgery Made Easy, I think I got the title right, which is 1) it’s a very thin book and 2) it’s a really quick and simple guide to understanding some of the basics of doing user testing.
If you hired someone to do usability testing, they would know a lot more and it may well be worthwhile hiring somebody who is an expert to give you some teaching and tutoring and maybe doing it all the time, but get yourself involved with that and actually see what your customers actually do with your product and understanding the actual problem your customers are trying to solve with that and that will communicate so much about the mental model that good UX and design people have because that is the problem you are trying to solve. Next to that, I think the next useful skill is, I don’t know, that’s a tough one, I think it could be, there are a couple of different ways you can go, you can start on approaching some kind of, the frameworks you use with your design team, if you can get to the stage where rather than the design team delivering UI frames, delivering mockups in some other formats, if you can get your design and your UX folk to work with you to produce something like a live style guide where you are creating the interface and the elements and the product in HTML and CSS or whatever, so you’ve got a live demonstration of what those artifacts are rather than something else, that gives you both a common framework to talk to each other with and that can help you try out interface ideas that fit in with the design ideals of the product as a whole, give you a much better way of communicating and learning with the design team and with both sides, the designers working with the developers and the developers working with the designers.
And another thing is I personally think that understanding a little bit about the elements and heuristics that go into visual design, things like repetition and rhythm and visual hierarchy and there are a lot of introductory graphic design books whose names escape me right this second, obviously, that help communicate these. And again, they are not going to make you an expert, they are not going to make you a great visual designer, seeing the differences that might be significant or trivial when you start tweaking designs that are given to you. I worked with a really great developer many years ago and he was delivered a picture of how the interface should be by the designer and what he produced was something that did functionally everything that that original design did, but the visual appearance, the usability of that was completely different to the level that the background color was different, the structure, the layout of all the items was different. That’s an extreme case and he wasn’t being malicious or disobedient in any way, he was honestly trying to build what the designer told him to build, but what he saw in that was the functionality rather than what as far as he was concerned was the incidental way it was structured and laid out. Understanding a bit more why designers structure and lay out in a certain way can lead you to see the problems in the changes that you might be making to that and appreciate the layouts and start building the things that help support that in your code base rather than having to do it manually all of the time.
That’s a tough question and to some extent it depends on whether both sides want those walls broken down and I have seen massive resistance from both sides. From the developer side it’s often changing the definition of success because in an Agile team you can be in a very comfortable position of the product owner asks you to build something, you define all the acceptance tests, you build what they ask for, it does what they asked it to do and then you deliver and you sign off. That’s the end of your job, your quality and position in that company is doing that job well. As soon as you start having to take on some of the building the right product responsibilities, suddenly that’s not the end of your job anymore, suddenly it’s a very fuzzy thing in the world that you have to define success from and that can be a little bit nerve wrecking, I think, you’ve got things that are outside your direct control to deal with.
So I think accepting that and having an organizational structure that allows people not just to be judged on those things, I think developers end up ignoring design often because the organization scores them and values them on metrics and models that exclude those factors. It doesn’t matter to someone, I am not going to get any more appreciation or money or brownie points from my organization from building something that the users actually want, you only get rewarded by building things, so you are going to build things, you get what you measure for. From the designer side, again there is a breakdown of responsibilities, often a siloed design group is marked and scored by the organization just by the artifacts it delivers to the development team, so yes, you complete your lovely wire frames and your lovely mockups, your lovely Flash prototype or whatever and then your job is done and if the development team delivers something no one uses, that’s their fault, they built something wrong, or something changed, it’s not your responsibility, you’ve already been marked and you’re already working on the next project.
Changing both of those things is a huge change in responsibility from both sides, the designers are going to be involved right from product conception all the way through to delivery, the developers are going to be involved earlier in the project when you are still figuring things out and they are hopefully going to be scored on the product, everyone is going to be scored on how successful the product is rather than I built what you asked me for. And those are really driven by organizational cultural values, sometimes those could be bottom up, you can get people on the team who value those things, you’ve got Agile transitions happening from the bottom up, people value building software the right way, people see value building the right thing and they are looking to make those changes and those changes can push you out from the team into those siloed groups. Sometimes you get more organizational top down change where people are understanding that we are delivering the wrong product, we are not making our customers happy and then they are looking for solving that problem, they are looking to address the fact that the design teams are not necessarily getting the feedback that they need from the product development process and vice versa. And then you are looking at breaking down organizational lines, you are trying to move people to be more about product development rather than design and development and that change in structure in an organization is a hard one and I don’t have an easy answers to that, it’s one of those things you have to take on a case by case basis, look where the biggest pain points are and try to address those in whatever the most appropriate way is at the time.
7. What’s next for you? What’s got you excited?
What’s got me excited here? What’s got me excited here is a lot more acceptance from the Lean startup, a lot more interest in the whole Lean startup, Lean UX stuff that’s been happening at the conference. I’ve been talking to a lot of people, who are going “yes, this really makes sense for me, this is really going to solve the problem for me at my workplace” which is exactly what I’ve been wanting to hear, back to what I’ve just been talking about, people have to want to see the problem in order to make the change for it to be really effective and I think people are really beginning to see the problem now and are looking for solutions and the stuff that’s being presented here and I think we are seeing more experience reports this time rather than the last couple of times I’ve been here, the Lean startups come up on occasion, but it’s been much more “here’s a cute idea you should maybe play with”.
This time people are coming back “we’ve played with that, things went rather well”, and those stories I think are convincing more people this is an effective way to make change and an effective way to start building teams and that excites me a lot. The other thing that excites me rather a lot is the general change in terms of bringing business people and design people and developer people together in the same environment and what I am really interested to see in the next few years, in the next five- ten years is how the communities have practiced change, as I’ve said, most developers don’t have user experience and design skills, most user experience folk don’t have development skills beyond the very basics of HTML and CSS and maybe a sprinkling of JavaScript. I think we are going to see that change over the next few years, and often neither group have any real business understanding, how to build businesses, how to make money, run organizations, plan products and product portfolios and I think we are beginning to see a merging of skills, I am seeing more business people looking to learn stuff from more generative end of user research and user experience, they are going off and learning interviewing skills and customer development skills and more ethnographic-y stuff, and you are getting user experience people who are looking to business stuff so they can be sure they are building something that will have business success and they are also looking to development so they can help build the products more. Development, I’ve seen a lot more developers that are actively keen to learn more about user experience, interaction design and realize that not having those skills is stopping them producing their best work, and many of those because of the kind of culture around, starting up your own side project and stuff like that are learning more business stuff and even if most of those products and projects are probably doomed, that understating is going to help them be better developers in organizations that are businesses.
Whether we can have some new job titles, new roles and new communities of practice, we have terms like growth hacker, which is half way between marketing and development, are we going to have new roles and new descriptions, we have people that are bits of user experience and bits of developer, that’s the hunch of the way I think it’s going to go, because the number of things we are building, software is still eating the world and we are still building new things all the time and because the quantity of software we are building is getting larger, and the number of people to build that stuff is not keeping pace with that, we are building more things with smaller teams and smaller projects. And we’re seeing many organizations, sometimes triples of these little things- business, developer and designer sort of thing, and the more skills people have in common, the smaller those teams can be and still do useful, productive work, so I think we are going to see some really interesting changes in what skills and qualities we look for in the people we hire and the skills you develop as you want to be a good developer or designer or good business person.
Todd: Thank you very much, Adrian.
Thank you.