Thanks for coming. I have a little studio in the back of my house where I do most of my work, and so I don't ever see this many people at one time, ever. So, I'm a little bit nervous. I wanted to, before I get started, if there's any back channel conversation about where I'm going to say,

just go ahead and tag it with MatterHack, and then I'll be able to kind of follow up and participate. So, about me, I'm an entrepreneur and a designer and a hacker. I was classically trained as an artist in New York, so I made the transition from painting and oils to coding.

It was kind of a fun little trip, but the thing that I found really useful about that was it was easy to get beat up in art school, because people just rip your stuff up, and then to go to try to work with a client when they don't understand what you're doing, or you haven't communicated well, and they can rip you a new one, and it's not that much of a big deal.

Right now, I run a small company with my business partner named Pure Blue, and we primarily focus on behavior design and healthcare, and I'd be happy to talk more about that another time. So, the first thing, as a speaker, I want to say thank you to all of you guys, not only for being here, but I spent a lot of

time on IRC over the past 10 years, and you guys have helped me out at 2 o'clock in the morning when I'm trying to figure out a problem. And literally, if it wasn't for you guys, I would not be able to feed my family, and I would not have the opportunity to pursue the passions that I have. So, thank you very much, and I'm hoping that this is a little bit of a give back for you guys.

So, how many of you guys are building your own web apps for yourself or for your own startup? And then how many of you are building web apps for other people, clients, that kind of stuff? A little above, good. Okay, cool. The things I want to talk about today are not necessarily about building another social network,

or another analytics tool, or another way of connecting Twitter and my, whatever music I'm listening to. And if you're working on those things, I apologize if I've offended you, but I want to talk about finding real world problems and trying to provide solutions to them.

I think that there's a couple really key things about the stuff that we need to work on and how to help those problems be solved. As an example, obesity in the United States is a huge problem, both financially and from how it affects the people that we know and love.

It's a big contributor to diabetes, heart disease, stroke, and cancer. A five-minute Google search will show you all kinds of stuff to get you excited about helping find solutions for obesity. It's a $190 billion a year problem.

And this is just in paid medical costs. This isn't even around lost productivity or anything else. This is just what we pay in the United States around medical care around the problem of obesity. It's a $14 billion problem in children alone. It's a significant deal.

And one of the things that can really help in dealing with obesity is simply going for a walk. Getting up and moving around. A lot of literature that you'll see will be exercise. And I made the argument recently that exercise is something really hard to get users to do. Because if you do a Google search right now for exercise, you're not going to see anything in there that looks even remotely like what you look like.

Unless you're like one of the one or two percent of us who are really in shape. So, and I don't mean us, I'm not one of those four. But the stigma around what exercise is and how it works is a really, really challenging thing to overcome.

Especially when you consider things like gym advertisements as you drive around your town and you look up at the billboards. I don't know anybody that looks like that. I would like to, but I don't. And I think the idea of walking or just simple movement is something that could have a huge impact and could really help fight the problem of obesity in the United States.

Of course we can look at high sugar drinks and all that other stuff. But the reality is that going for a walk has other implications as well. It helps offset depression. We found that in 47 percent of folks who deal with depression, going for a walk helps decrease their reported depression score.

So, moving around and having some sort of movement is something that could be done and would help a lot of people. And I think that in this room, we're uniquely qualified to provide tools that would help people be excited about getting up and moving around.

I think that there's some pretty awesome things that we could be doing as far as gaming is concerned. Just basic email using the, I mean, who's sort of Django drip, the drip library? So using that as a tool, you can create an email drip campaign on whatever app you're using that will remind users

that they want to come back to the application and use it so that they can continue to get up and move around. There's all kinds of stuff that we could be doing. There's a lot of problems that need our help, our unique skill sets to be able to help them.

Mental health, poverty, education, social justice, the environment, wounded warriors, and many, many, many more. These problems are all in the domain of being able to change behavior. So if you can create an application, like a game, that changes people's behavior, perhaps you can do it in a way that would benefit them or benefit society.

My business partner and I have a little passion project that we're working on for fly fishing, and it's really just a simple fly fishing diary. We live here in the northwest. I'm way more comfortable on a drift boat on a Mackenzie than I am standing up here on the stage. And we built this app so that we could start to look at ways to collect data and make those data points

more accessible for other folks so that they can understand how the fishery help is, the river systems that are all around us. So building things that matter, building things that can actually change lives or have a real positive impact are something that I feel like we're uniquely qualified to do. The problem is, if no one uses it, it's not a solution. If you

build an application and no one uses your app, then you haven't really solved anything. If you build an application and you get that first thousand people in and registered, and then you have fall off after, say, two weeks, three weeks, how do you know that you're actually affecting behavior?

So if you agree that there's things that we could be doing to really help change people's lives, then what we need to really look at is adherence to our solution. So what I want to spend the rest of the time talking about is the idea of how we build a process that enables us, using Django tools, to keep people excited about the application and making sure that they stay engaged.

So this is obviously a graphic that I created to just kind of illustrate our process. It's a pretty simple process, and it's designed to be simple on purpose.

Our first phase is a sketch phase. The second one is prototype, and the third one is build. So obviously, a lot of this is going to be really kind of base level. You probably already have gotten all this stuff. The sketch phase is designed to capture the ideas really quickly and easily.

The prototype phase is designed to deliver something that people can play with. Sort of like if you took your sketches, you're working on a painting, and you took your sketches and handed it to other people and said, you have lines to it as well. And then the build phase is where we actually build the application.

Before we begin sketching, there's three things that we try to focus on doing, because otherwise, who are we sketching for? Maybe in our own curiosities or whatever. We need to make sure that we have users, and this has been something that we've talked about in the projects that we're working on pretty consistently. There's nothing about me without me. I wish I had been clever enough to come up with that, but this was actually brought up in a seminar.

And the idea is that if you're building a tool for me and you don't include me, then what are you doing? There's no point in continuing with your application if you're not including me in the process. And by me, I mean me as a user.

So one of the things that we really focus on and spend a lot of time on is identifying what the problem is and then what the solution is. How many of you guys have read Lean Startup or Running Lean or any of those? Okay. So I would strongly, strongly encourage you to go out and get those books.

There's some really great practices in there about identifying whether or not we're actually solving the right problems when we're building software. I'm going to say this a couple times. You guys and us as developers are pretty intimidating people often.

When we work with our stakeholders, when we work with our users, we know a lot of things about specific pieces, and sometimes it's a real challenge to have a conversation with us. So we might look at something and say, oh, I seem to have developed a solution to this, or I know what the problem is, so I'm going to go solve it.

And then if we don't encourage users to participate in the conversation with us, then we end up kind of drifting down the road, a rabbit trail, and building something that doesn't actually work. Doing this, if you guys get Running Lean and read through that book, I think you'll find that there's some really great methods in there for validating what you're trying to do before you actually do it.

A couple years ago we were working with a client we had a good relationship with. This was about the fourth year of working with them, and they came to us with an idea for a new project. It was pretty exciting. It was going to be an aggregation tool that did a whole bunch of cool stuff.

And they were starting to allocate budgetary, they were starting to build up the internal political approval, and we were all set and ready to go. And I said, I had just finished reading this book, and I said, well, hold on a second, let's make sure that we're trying to solve the right problems. So we proposed, we worked with the stakeholders, and we proposed these are the three problems we're trying to solve.

And we sent that out in a survey to their constituents. And we used Google Forms, and they went through and rated all the stuff. None of the problems came back as rating higher than, say, a three, on a scale of one to ten. And it was a good thing that we did that, because what ended up happening was, the stakeholders said, well, we're not

going to allocate all this money towards this if we don't know that this is a problem that actually needs to be solved. We perceive it as a problem, but our users don't actually see it as a problem. They have a whole different set of problems which came back as a unique opportunity for us to take advantage of.

So being able to identify what the problem is, is super, super important. Using Google Forms to do this is one way. Obviously, user interviews is another. You can sit down with users, talk to them, talk about what are the problems that you have in this regard. If we go back to the walking idea, what prevents you from getting up and walking around? What are the kinds of things

that you could do that would offset or give you the opportunity to take a walk that maybe you hadn't thought of before? So having and understanding this problem piece is 50% of what you need to understand before you start.

The other 50% of it is, what's the solution? So if you can get an agreement from the people that you want to solve a problem for, you can work with them, they can help you identify a priority, what are the top three things that I need to solve, or problems that I have. And you can create solutions for this. And this is just Google Forms, right? It's just,

you're just typing stuff out. You haven't written any code yet. You haven't done any drawing, nothing. They're just talking with you, you're dialoguing, you can develop some solutions, coming up with ideas, and you can use this now to develop your product. This may suggest to you what your primary function of your product is. When we were looking at the fly-fishing app, one of the big problems that

I had was I would come off the weather, and three days later I couldn't remember what had happened, never mind what I had been doing the year before. And I had no way of knowing what the population difference was between one year and the next. Fishing reports are, you know, not very good for that kind of stuff. So identifying what the problem was, we talked to a bunch of other fly-fishing

folks and we asked them, what are some problems? Well, I can't even remember what's happening. I know that I have these flies available to me, but I don't remember when I'm supposed to use them. So the solution was, well, it's a simple battery app. You just track what you're doing, select the weather, some basic science stuff, and then you've got the information that you need to do.

So coming up with a solution was based on specifically what the problem was. For another project that we're working on right now, Manage My Fatigue, we're working on developing an app that helps people manage their fatigue levels, specifically to start folks with traumatic brain injury.

So we needed to be able to look at what are the problems that people have when they're trying to manage their time. Energy retention or keeping their energy levels up is a real struggle for this population. So knowing how to identify what were the problems. Something simple that I may not have

come across was, I need a visual cue that tells me when the timer is up. Not only do I need some sort of messaging, some haptic response or something like that, but I need the screen to actually change so that I know something's happening. Little stuff like that. So these are different pieces that come out of first identifying the problem and

then identifying the solution. The last little piece of this is building user advocates. These are people who in essence as your users become your friends. In all honesty, you develop a trust relationship with them, you ask them questions, they give you the feedback. You need to have a thick skin because if they're honest, they'll tell you when something you're doing sucks or when something you're doing is great.

User advocates are somebody that you can go back to consistently. They'll be your early adopters. They'll be the people who are passionate about what you're doing as well as you, but they maybe don't know how to write code. Often, they have a vested interest in knowing that this thing works for themselves. So they will work with you and are much more

tolerant of the mistakes you might make in your assumptions as you go along and are happy to help set you on the right road. Additionally, these user advocates are somebody or is a group or a population of people

that are going to stick with you through the whole project, beyond just your initial launch. They'll continue to stay with you. They'll be excited for you. They'll continue to provide you feedback. These are the folks that you'll get an email from at midnight or four in the morning. Hey, I thought about this or hey, when I did this, this didn't work, et cetera.

Or you forgot to turn the debug off and now I'm getting code on the page. The sketch phase is about pretending. If you identify the problem, come up with some solutions. Your users agree, yes, those are great solutions. Those are things I'd be excited about. The sketch phase is about pretending that you have the thing already. So you're wireframing. How many

of you guys actually wireframe in your projects? You wireframe out views and that kind of stuff. So this is incredibly inexpensive. And if you're not doing it, you definitely should. This allows you, even with just a piece of paper, to draw out what you think the view is going to look like, maybe what the form is going to look like, what the feedback potentially is going to look like.

This will save you so much time and effort. You can use Google Drawing if you don't want to just sketch and you're afraid of doing sketching. And I'm a big fan of a service called Balsamiq. I have no professional relationship with them other than I'm a paying customer.

They've got a great set of tools that you can build together in UIs in a matter of minutes because they've got a library of all different kinds of widgets. The principle is not this is my design I'm giving you. The principle is this is a potential experience. Can you use this? That's why going through this process, using this piece of it, is a really, really important part. You can get

users and build momentum by doing this. So if you have your user advocates and you start testing this stuff with them, ask them to share it with other users so that those folks are also excited about what you're doing.

This is a screenshot of the timer piece and as I was referring to the left, this is a normal countdown timer and the feedback we got was I need some sort of visual cue that the timer has changed so we turn the screen red under five minutes. There are some assumptions I made as a designer in this screen which turned out to be wrong. And it's a lot around

the iconography. All across the top, on the left and the right, and on the bottom left. There's a lot of icons on the screen. And justifiably so. It's a mobile view. I need to fit a lot of information and functionality into a small screen. The problem is, feedback came back, I don't know what these icons mean. And I don't know if

you guys have struggled with this or not. I recently wrote a blog post saying to get rid of all icons, strip everything out as much as you possibly can because there's no common vocabulary around most icons. Most of the icons we look at are interpreted by the designer and the team that's building it. They're not

based on the universal principle of understanding. There are a few, yes. But most of them, I would argue, are not. If you use this process, you can iterate quickly. So I can draw a sketch, I can put it in front of users and say, what do you think? I've even done things where I've drawn something out, taken a picture of it with my phone and emailed it to them. Tell me what you think of this. That can go very quickly.

This is useful because you can build momentum, like I said earlier, you get people excited about what you're doing, you're responsive. So if someone tells you something, you can push that right back to them if you have, say, user advocate group of around five users. If you have more, say 20 plus, you can synthesize all the feedback and you can say,

this is what other people are saying. Here's all the different stuff, the feedback, all the different input I'm getting, and then return that to the user so that they have something that they can understand. Making it accessible is super important too. How many of you right now, if you had to, could actually type out your Basecamp password? If you're using Basecamp, so a couple.

Most of the users that I'm working with have a hard time even with login screens. And not because login screens are necessarily difficult, but because they have so many services, how am I supposed to remember what this password was?

So while I really, really, really, really like Balsamiq, the login process is difficult for some of my users. So if I give them access to some screenshots, they have to login in order to leave their comments, and I will often get emails that don't remember my password. They're emailing me because I'm the face that they're interfacing with even though I don't remember my password. Same thing happens on Django apps.

So I'll back stuff up with a PDF of the actual last names in case that happens. I can send it off to them in the meantime while I help figure them out. And I can even just use raw HTML. I worked on a project for helping kids with depression talk to their parents about depression, and we built a game.

And when we initially got started, there was a lot of things that we were trying to figure out, and almost all of our prototyping that we did was all just raw HTML with no styling. Because all I needed to do was understand what would happen if the user, I mean,

all I needed to know was does the user understand what will happen when I click something? Do they get the idea that I can do something and then something happens? Right? So that was easy to accomplish with just real basic HTML. And it's got to be fast. If it takes a month to connect with your users, send them stuff, process it, and then get

back to them, your users are going to lose interest and or they're going to forget what they were already working on with you. So you've got to be fast, you've got to be responsive, you've got to get back to them quickly.

I had the good fortune of working with a guy named Rob Hudson and a guy named Percy Perez. And I wish that this idea was my unique awesomeness that I came up with, but actually, it was these guys. And at the time, I was a designer just doing front-end design. And these guys were really smart folks.

And we kept having this problem going back and forth around, I wanted to do this, but I want the functionality to be X, Y, and Z. And they said, I don't know what you mean by X, Y, and Z. And I'm like, well, what do you mean you don't know what I mean? It's right here. Look, you can see it on the Photoshop comp. It's all really clear.

And their pushback was, I don't know what it actually does, right? So I don't know what kinds of things I need to do in the background. So we switched. And they said to me, you build me a template first, and then I'll do the modeling after. And I'll create the views and all the beta models based on what you give me as a template.

And I hope I'm not outing them about anything. But that kind of turned my whole brain around. So the idea is that I'm not going to start with my dataset. I'm not going to start with my views. I'm not even going to start with my URLs. I'm just going to create a basic template. And I'm going to start there and start showing the things that I want to have happen on the screen.

For that reason, I'm sure there's different, I have forgotten by now, but there's different Django starter kit libraries. I just usually start with just the basic Django install and then static files and flat pages. So that I can start building stuff out and getting access to the templates and start iterating in front of users.

So it's so quick to be able to, you know, and then I don't have to do south migrations or whatever, depending on the version you're on. So I can build out the templates, modify my HTML, make it do stuff in front of my users, have them give me feedback and make changes. So this is something, instead of pair programming with another developer, I can pair program with my user.

We can sit there together, obviously they're not programming, but they can look at what I'm doing and say, does that make sense, does it make sense, move it up here, I don't understand what you're doing, et cetera. And then some of the front-end frameworks that make this, you know, go quickly, bootstrap, Gumby, foundation. What you think about those as far as a front-end development framework for later on is a different question.

For me, in this phase, it's really about do I have a solution nailed, does the user experience make sense, when the user clicks on a button that says add note, does that experience feel right to them? Are they excited about what it is that's happening?

The other thing that I did probably about four years ago is I completely stopped using Photoshop, or any other 2D mock-up tool at all. And the reason is, I cannot get the same feeling and the same experience in a 2D mock-up

that I can with a template or something that I can click, especially if you use responsive design. Using responsive design, you can build a model that works on a phone and is accessible by a URL. So you click it, it does something.

You click it again, it does something else. I can't emulate that in Photoshop. So what I found was I was spending a ton of time and effort on my mock-ups to communicate all these different views, you know, in-board messaging, on-boarding system, you know, all kinds of stuff. And it just was not working.

And I figured, gosh, if I just get rid of Photoshop and stop doing that all together and just jump right into the HTML, then I know that I can be able to communicate things quickly and easier and get the feedback I need in order to keep things moving. And so far, we haven't really edited it. It's been a really positive experience not using Photoshop as a mock-up.

I meant for doing mock-ups. Yeah, if I can't touch it, it doesn't exist. And again, another reason to not be using Photoshop. So if I can pick up my tablet and do things on my tablet, if I can pick up my mobile device, I can pick up my laptop, whatever, and actually do something, even if it's completely fictional,

that gives me better feedback than having a user look at something and pretend to click it. Has anybody heard of Heap Analytics or Kissmetrics? Okay, a few people have heard of Kissmetrics. So Kissmetrics is kind of this awesome data opportunity.

You can use Kissmetrics to track all kinds of stuff. For instance, let's say you have a tool and you want to do a conversion from a user who's registered all the way through a fulfilled shopping cart. You can build a funnel report in Kissmetrics that tracks the entire experience for a specific user and tells you where they fell off.

So I've used Kissmetrics to look at online education programs for advocacy stuff, for instance, traumatic brain injury, and we knew that at some point users were falling off. So the idea was we wanted to identify what was causing that falloff,

and we used Kissmetrics to look at the data and come back. Heap Analytics, I think, is relatively new, and what they've done is they've kind of done this similar thing for free. So you plug in a little JavaScript on your HTML, and you can use this on your prototype or your actual build,

and you can look at the data and all the falloff and all the different conversion rates, et cetera. It's pretty awesome. If you remember, I showed you a screenshot earlier with icons. The feedback we got was I don't really understand how the icons work. This is a screen grab from the alpha version of our app, the Manage My Fatigue app, and we convert it to text for navigation,

and it's been way more useful, because users aren't stumbling over what the icons mean. They don't have to learn a second vocabulary as long as they speak English or can read English. So they can use this app and jump around and can see things quickly and easily, and there's much less cognitive load as far as,

well, perceived cognitive load, as far as trying to understand how the UI works. Like I said, using templates and Django flat pages, I just install, you know, do a basic install, get things built up. You can start building your UI off of Django flat pages and building your URLs.

Okay, so I just recently started using Angular on my front-end, and basically the way we do stuff is we use Django for all the back-end stuff, then we use Django rest framework for the API, and then everything else is done in Angular on the front-end. We're still working on user authentication,

because that's kind of a tricky way to... But what's cool about this is the work you do in getting your prototype ready, is actually building your app, if you're using one of these front-ends. So you can emulate all your data stuff with JSON, just like you would fixtures,

and you create your JSON data, set it aside, and do your API calls against that JSON data file. You still haven't built any data models. You still haven't messed with anything on the back-end of the database. It's all just in the front-end. But you can get pretty damn close with this. And it's, to be honest with you, I have a doll.

I haven't played... I've done a little reading on Ember, and haven't played with it much, and I left Backbone out as soon as I've done Angular. Okay, so build. So you've iterated through this with your users. You've put out releases. You can set up an HTML, just static site.

They can access stuff. They've played with it. They've given you feedback, and now you ship it. And I would strongly, strongly, strongly encourage you to use something like heap analytics, or kissmetrics. And now you're starting to iterate, not only with user feedback, but with user data. And I can't tell you how many times I make assumptions about how something works,

or what the user experience is, only to have this data show me that it's completely in the other direction. I'm a big fan of Django REST framework. I think it's a fantastic tool. But one of the reasons I love it more than some of the other API tools is because of this.

So I can build an API and play around with stuff, and I can test alternative methods. So obviously I'm in the build phase now. So I'm building my data models. I'm getting all the database stuff moving. And I can build my front-end in Angular, or whatever, however I do it, old-school Django, whatever.

But this tool gives me the opportunity to have a whole other interface that shows me alternative views. And what's neat about this is I've actually shown clients... I'm sorry, not clients, users, this view with Django REST framework. How many of you guys are using Django REST framework? Okay, sweet.

So I've used this with other users, sat them in front of it, and they're like, oh yeah, I can see. You get a list view with the creation thing. You have to translate a little bit for them, but it can be a useful exercise in how do you want this to work. And in fact, this method I used on a recent project where we had a list view of stuff, and because it's a single-page app,

I was able to make the add screen and the list screen in the same view, and the user really appreciated that because then you have to go back and forth between page refreshes. And the idea came from how those are set up. I think feedback obviously is really important. I highly recommend you systemize it somehow. Depending on your population, GitHub can be really useful.

If you do use GitHub, you need to know that they obviously have to create their own account. They need to work through them. What does it mean to submit a ticket and how do I make it useful? Google Forms is another great tool. I use Google Forms all the time. I really, really, really like Google Forms.

Jenga Feedback is a side project that I had a while ago. It's pretty outdated at this point, and the reason is I had a whole project and what I now end up doing is it stopped asking the user to please tell me what browser they're using, what version, what all those other things. I just, when I have any feedback form that's integrated into my systems,

I'll now just add in that second line and I send myself the user agent and it tells me everything I need to know. Well, most everything. And then they all give me the feedback so when I get that feedback email, I get their note with all their user agent stuff. It makes it easier on them because they don't have to worry about translating something that they don't necessarily understand.

I highly recommend that you try to keep data collection as simple as possible, at least in the beginning. You use one service for data, so it might be one for monitoring, like New Relic or something like that. But try to keep your data sets as small as possible because those data sets will grow quickly,

especially if you continue to solicit feedback from your users and they're excited about what you're doing, for instance, via Google Forms or something like that, you'll collect a database with lots of records and lots of feedback. So the process we use, Sketch, Prototype, and Build, has been really successful so far.

We've had a lot of good experience with it. We've saved a lot of time by cutting out some of the Photoshop stuff. And by replacing it with live templates that we're building on has been really useful. Special offer for you guys, I built templates for both the problem and solutions

interview piece. If you're interested in using those in your own work or taking them and running with them, you can just go to gameover.com slash email, sign up, send me your email, and I'll send you the problem and solution templates. Okay, any questions? We don't have time.

Oh, sweet. Any questions? I think so. Thank you very much. That was very salutary advice.

I don't know what you think about this, but one of the things that shocks me most about software developers is how often they don't use the things that they're actually building themselves. So they are entirely reliant on the user.

Whereas if you build something and you are also the user as well as the builder, if you've got to live in the house that you've built or eat your own dog food or whatever metaphor you'd like to use, then that loop is very much tighter. And I think it should be compulsory by law

or obligatory for developers to use this stuff. And you're not even allowed to develop something unless you're going to use it. So my thought I want to say is do developers eat their own dog food, for lack of a better term?

I definitely agree. I think that we do need to use the tools that we create. One of the things that's really challenging is, especially with most of the populations that I work with, there's no way, even if I use the tools, that I'm going to completely understand the problem set that they have. This past spring I got to be at coastline community college

where we were testing to manage my fatigue app, and I sat in a room. We had three, I think three sessions, 20 students each, all had a traumatic brain injury. There's no way I can fully understand what it means to have a traumatic brain injury. So I would definitely agree. We need to eat our own dog food, but we also need to become friends with our users

because they're going to communicate to us, whether it's easy the first time or not, what it is that we're doing, and whether or not it works. Does that make sense? It must be easier to be your own user when you're writing a CMS than doing something like that. Correct. Thank you very much.

It seems like you're doing a lot of user-centered design, which is awesome. I would love to see all companies do that. Yeah, my question is, did you ever need to account for users bias? Meaning, you know,

when everyone says that people ask for a faster course, did you ever have to account for people giving you some solution that's not necessarily the best? Yeah, so the question is, do you ever get recommendations that the question is, do you have mechanisms in place

to compensate for this bias, or maybe you just never needed to because your users are, you select your users in a particular way so that... No, so for us, one of the challenges is

we get a lot of really good feedback. So managing all of it is about time and budget. So many of the things that, if they're not in that specific problem set that we established in the beginning, then we backlog it and figure out when and if. I've actually taken things out of that and put it in front of my users and said,

hey, what do you guys think about this? This may be a really good solution from one user. How does everybody else think about it? Is this something that we need to consider? Do we need to change our priority? So it's just about conversation. Another question then.

I used to work at a university where I worked for them,

and I was the biggest user of this. We had another 50 or so users who were also collaborating on them. I was in quite a fortunate position because even though my users were often completely wrong about how this should work

and what it should do, I was also the most important user, the biggest user in the system. What do you do when actually or the desires you get from users doesn't follow best practice, or isn't actually going to do the things

that they think it's going to do, or your users want things that they should not have? Yeah, so that's a really good question. What do you do when your users make recommendations that either they might be flat out wrong, or they might be recommending something

that's not in their own best interest, or something that's not in their best interest? For me, it's about being able to dialogue with them. It's about being able to, if you have that trust relationship, then you can say to them, no, that's not a good idea. Or if it's really important and you don't understand, which I think is a big issue a lot of times,

is help me understand why this is important, or is there something else that we can do that helps you accomplish what you're trying to do without actually compromising the law, or violating copyright, or there's a lot of misunderstanding. I let people go, why can't you just copy the source from that page, put it in that page, and you'd be good to go? Well, because you're stealing someone else's IP

and you don't look good when you do that. So, it's about building that trust relationship. That sort of reminded me of a similar question. One of the things we find that's extremely difficult is taking features away. Once you put a feature out there,

it's really hard to tell a user that, no, you can't do this anymore. Do you have any experience or thoughts on how you can do that in this process you outlined? Yeah. So, the question is, how do you take features away or avoid the issue altogether?

For me, it really goes back to identifying the problem solution set. If you only have three solutions and you try to make those solutions as simple as possible, and that restricts the amount of stuff you actually produce. So, the fly fishing app is a great example. We wanted to do all kinds of cool stuff

like geolocation and, you know, go on and on and on. The reality is it was cost prohibitive to do it. And if I had released that as a feature, I would not have been able to support it. SMS messaging is another thing that we run into a lot. We would love to be able to implement SMS messaging. We have the code to be able to do it.

However, if you implement that, you now have to pay for it. So, there's an unforeseen budget ramification. So, for us, it's about shipping things that are as small as possible. When it does come time to actually have to remove something, that's a marketing opportunity. If you can take the time and justify why you're doing what you're doing and explain it well to your users,

gives you another chance to connect with them. You may piss some of them off. However, you do get to have an honest dialogue with them.