16: Kurt Schmidt - Project Management and Mobile App Strategy

Tim interviews Kurt Schmidt, President of Foundry and former Director of Project Management at The Nerdery, who takes him to school on how to effectively strategize and manage the development of a mobile app.

In this episode, you will learn:

• The importance of a mission statement in driving all product decisions
• What differs in managing a million-dollar app project versus a thousand-dollar app project
• Why you need to include your development team on the macro decisions of your company
• Why it’s not enough to know “who your user is”, but also “where your user is at”

This episode is brought to you by The Jed Mahonis Group, who builds mobile software solutions for the on-demand economy. Learn more at https://jmg.mn.

Recorded July 13, 2018 | Edited by Jordan Daoust

Show Notes

• Foundry
• The Schmidt List
• KRTSCHMIDT.COM

Episode Transcript:

Kurt Schmidt 39:07
Sure.

Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non-technical look at mobile app development. I'm Tim Bornholdt. Let's get nerdy.

Today we're speaking with Kurt Schmidt. Kurt is the former director of project management for the Nerdery and the current president of Foundry. He at Foundry leads product design workshops and drives digital transformation initiatives for all his clients. He's also the host of the Schmidt List podcast where he interviews leaders in design and technology. As I mentioned in this episode, I really couldn't just limit myself to discussing either project management or product design with Kurt because he's really an expert in both. So as a bonus, you get to hear us discuss both.

In this episode, you will learn the importance of a mission statement in driving all of your product decisions, you'll learn how project management can differ from building a $1,000 app to a million dollar app, why you need to include your development team on the macro decisions of your company and product, and why it's not enough to know who your user is, but also where your user is at. After we stopped recording, Kurt and I talked for another 45 minutes and I learned a ton from him. And I know that you guys will as well. There's some very, very actionable advice that you can take to apply to your mobile app project.

So without further ado, here is my interview with Kurt Schmidt.

Kurt Schmidt, welcome to the show.

Kurt Schmidt 1:42
Thanks, Tim. I'm glad to be here.

Tim Bornholdt 1:44
Excited to have you. I know what you're a very prolific individual in the Minnesota tech scene. So I'd love if you could give my listeners just a brief rundown of who you are and how you came to be in your various roles throughout the community here.

Kurt Schmidt 2:00
Sure, yeah. Well, you know not to tell you my entire life story. But I started out as a designer and developer and I'll date myself but I started back in the CD ROM days, building CD ROMs for health insurance companies to explain their your health insurance. You'd get like a little folder and a CD ROM. You could put in your computer and multilingual, interactive, all those things. But over time, I found you know, this thing called the internet was really exploding and it was, you know, it seemed that the hard materials, the hard deliverables, were going the way of the dodo. And it was time to jump on this internet bandwagon. So started, you know, just like a lot of other folks, designing and putting together custom websites for folks and then eventually joining a small agency and it grew and really became very popular and started growing. So, you know, I was helping hire folks and bringing people on. And then I realized over after a year or two of doing that I was hiring people that were much better developers and much better designers than I was, which was a blessing. But at the same time, you know, I had to struggle with the decision that I was much better at leading the teams than I was at actually doing the work.

And so from there, I went to a place that was pretty small at the time, called Sierra Bravo, which eventually became the Nerdery, and I joined there when it was about 50 or so people, and then joined there in the project management team. And basically, helped open up a number of the remote offices. I led the project management team. There was about 50 project managers around the time when I was really in my stride, 400 active projects, so probably responsible for about $300 million worth of software during my tenure, then helped launch the strategy side of things at the organization. And then, yeah, eventually found a group of people that I knew through some friends that were building a product design agency. And in doing a lot of coaching with them, because they were growing quickly, they needed a lot of help with that from somebody who has experience in a fast growth agency or firm. And so eventually, I just hitched my wagon over there. And that's now at Foundry and so I've been there for about a year and a half as the president and it's been great. We're having a great time.

Tim Bornholdt 4:47
And that's, like you were saying, that's a pretty prolific career and and yeah, it's great because the reason that I want to talk to you initially was through just talking about project management cause I knew of you from your time at the Nerdery. But as I went and saw you speak a couple of months ago, and you were speaking about product strategy, and I was like, well, man, now this episode's gonna be twice as long because I need to ask you some questions about product strategy.

So if you don't mind, I figured I'd split it up, kind of do two in one here. And then just kind of pick your mind on both hemispheres.

Kurt Schmidt 5:23
That sounds great. Sounds great.

Tim Bornholdt 5:24
Awesome. Well, let's kick it off with Project Management then. So I think everyone, even people that aren't in a leadership role or anything, everyone's had a project that they want to get done in their life. But I think sometimes people come to us when we're building apps for them, and they somehow think that building a technical project is different than, you know, any other kind of project. What do you see as the similarities and differences between managing an app development project versus managing something else?

Kurt Schmidt 5:54
Yeah, well, to that point, I think that's really interesting, Tim, that you put it that way because, you know, I think any other project if I'm, you know, building a deck or if I'm doing some other things, you know, there's a sense that when I'm done, I'm done. And even though as we all know, a deck needs upkeep and maintenance and things, we don't really view it when we build it in terms of a total cost of ownership, right? So it's like what they tell you when you buy a car, right? You're gonna spend this much a month in your payments, it's gonna cost you this much stuff, but there's the gas, there's the insurance, there's the oil changes, there's the car washes, there's a myriad of number of things that jump in there, but you never look at it and have those discussions in that same fashion.

So software is no different except for people assume that, you know, there is a state of done. There is a state where it is complete and now we will just use the thing versus when you look at companies like Google with Gmail or Amazon, and how they're deploying code every few minutes to production to make updates to things. You know, you're not sitting out of your deck constantly repairing holes as they're happening throughout the day. No, I mean, I hope not. You must really love your deck. But that's the difference I find in the conversation with people and how you have to explain it. You have to let them know that this thing has a life cycle, not necessarily a finished state. And to be honest, that can be intimidating for a lot of people. So my advice to people that are in the development or the agency business is to make sure you're tempering those discussions. You don't want to frighten somebody to think like, oh my gosh, this is gonna cost me millions of dollars for a long period of time, but you also don't want to give them the false sense of security that at the end of your timeline that you shared with them, that there is nothing else after this except for using it. So it's a balanced conversation.

Tim Bornholdt 8:06
Absolutely. And like you said, I think the key to any project is really communication. And that setting expectations is one part of communication of making sure that you're aware that technology isn't going to be standing still. I mean, I think there might be innovation in wood, but when you build your deck, it's not like the hot new wood is going to be coming around the corner in a month. Where like the hot new version of iOS is definitely coming around the corner in two months.

Kurt Schmidt 8:34
Yeah, and a new phone and all those things. You're gonna all of a sudden have to deal with notches and no more buttons and things. And especially in app development, you're developing on shifting sands a lot and a company has to be ready to make that investment and not just investment in capital or money, but in their organization and putting their organization and putting product owners in charge of owning these things and organizing themselves in a way that supports the technology in a much better way than they did years ago when you just had the quote unquote IT team.

Tim Bornholdt 9:19
So with those projects, like you were talking about with the product owners and giving them the tools to make sure that things are going well. What kind of systems would you suggest from the get go? On day one, like when you build a tech project, what kind of systems are you helping to establish with those product owners so that they're able to, I guess, see progress being made, but then also continue to see that cycle through as the product continues to evolve?

Kurt Schmidt 9:46
Yeah, that's a good question. I think that it's a number of things because as a company, maybe let's take a company, for example, that maybe is not super technology based, right? Maybe you know, for sake of an argument, an auto shop or something, a very large one, and they want to build an application of some sort. A lot of times they don't have the roles in place, or the processes or systems to handle the different way that technology works versus processing auto body fixes, right? They have different systems, and they build processes over time to make themselves as efficient as possible to doing the work that they're doing. But now they want to add in this technology piece. And it's really talking to them about not only the processes and things, but the roles and the culture around how they address them, right?

If you're going to build an application that allows customers to contact you directly through it, who's taking those calls on that other side, who's accountable, who's going to get those emails? Or I I've talked to companies that want to do a chat bot. It's like, great. You want to do a chat bot. Who's answering the chats at 7pm at night?

Tim Bornholdt 11:07
Well, the bot.

Kurt Schmidt 11:08
That's right. That's right. The thought is, yeah, but who's there? Who's going to be there to support that bot? Because it is not the CEO of your company. It is not the Chief Marketing Officer of your company. It's a bot. Right? But who owns those things? And what processes and changes are they placing internally, and that's why like at Foundry, we focus a lot of front on strategy first and on the business strategy of technology before we talk about technology or anything else. We really want to understand how is your company made up? Who does what? Who's responsible for this application? Who are the stakeholders? Who are the users? Who's doing what? And then putting together a plan that not only achieves the design and technology goals, but also brings it in for a great landing, that starts to add value on day one at the beginning.

So having those discussions up front is really important. So like I said, understanding their culture, how they're currently positioned, what processes do they already have. And then how can you now either lay on top or interweave or parallel these new processes around technology and design, I think is paramount.

Tim Bornholdt 12:27
That makes a lot of sense. With regards to project size, so if I'm coming to you, do you see a really big difference in how you manage a small app project versus a huge app project? Or is it pretty much the same thing, but you just have kind of more sub processes you have to deal with and more and more like that?

Kurt Schmidt 12:48
Yeah, I think it's really both to be honest. You know, there's a lot of similarities between, let's say, a month long project versus a two year project. Right? And I've been lucky enough to be a part of both sides of those things, and see the differences. Scale, obviously, is one thing, because you've got a lot more resources and bodies and things to manage in a larger project, because it's going to take a lot longer, so you need a lot more folks. But the thing is, what I've seen is people throwing bodies at a large project because they think that more bodies gets you more output, right? And as you know, Tim, there's diminishing return to having multiple developers working in the same code base. So I think the difference really is how you're splitting up the work and how you're managing those different work streams that all need to merge at the end. I think that's where I've seen on a larger project where people might take that small project mentality and just say, Well, I'll just apply these same processes into and tools I would to get something done in a couple of sprints, versus over the course of 50 sprints or something like that. And coming into it in a way where you really understand what the output is, versus the code, right?

One thing that I really coach people on is like, what is the shortest time to value versus what is the shortest time to production? And having an understanding of, like people like to use MVP, I'm not sure exactly what that means anymore. People use it in so many different ways. And because of that, it's the same thing I used to deal with back in the day when people would come in and say I need a prototype. I need a beta version. I need a first release. Every single one of those people, to a developer, it sounds like the exact same thing, but to each of those customers, they mean very different things. So for me, it is understanding on why we need to wait two years to deliver on value versus one month. And having those discussions. I think you have to deliver on value differently in those bigger and larger projects. Sometimes they can be more difficult to convince people. No, it's okay. Let's release it with just the one feature, and then add on later. No, no, no, my brand. It's got to have all these different features and all these things on it. And I'm constantly coaching people, well, what's the customer going to find the most value in? And let's go and ask them. Let's go and show them the prototype. And they will tell us what the quickest way to add value is.

So I guess long story short. The difference for me between those bigger and larger projects is understanding how we're going to present value to the customer, whether it be a business or an actual consumer, B2C, or B2B. And how soon can we get that value to start happening so we can get ROI on the system.

Tim Bornholdt 16:01
That makes sense. And I guess with that, like, when we've had projects that are in that larger range that take, you know, a year or two to build out versus something smaller. It seems like when you're at the starting line compared to when you're at the finish line, the starting line, when you tackle a small project, it's pretty easy because you can really see the finish line in sight. But when you're standing at the start line of a two year project, and you look really far into the distance, I mean, you can't see the finish line. So when you're doing something that's massive like that, do you prefer to do things like set milestones to get to that point? I mean, does it tie in with the value, like your philosophy on value, of setting milestones based on, let's get to this value marker first, and then go to the next one and then go to the next one?

Kurt Schmidt 16:55
Yeah, yeah, absolutely. No, that's a great way to put it. Yeah. And nomenclature aside, the thing that I want to do is get something in front of their end customer or end client or end business as fast as possible. I want the end user to steer what we're doing more so than I need the stakeholder to do it. I get it, like they have some needs, and they have some goals. Absolutely those need to be incorporated into every single build, and they need to be a priority. But at the same point, we need to bring in that customer and make sure that they are telling us what right looks like and what good looks like, every step of the way.

So you know, back in the day, we would put our heads down and worked for six months before there was even a first release. And to be honest, what came out of it was not exactly what the customer needed. It might be what they said they wanted, but it might not be exactly what they needed. Because as you know in technology, six months is a long time. Things change very quickly over the course of six months. So being able to communicate to the client all those different changes that are going to happen along the way and how you're going to address them, is really important. So yeah, setting those little milestones where we can take a look. And, you know, there's a great movie called The Hunt for Red October and the Russian sub would do this thing they call the Crazy Ivan, right? Where every once in a while, they just stop and turn around and see if there's anybody behind them, right? It's the same thing you do maybe in a sprint where you're calling it a retrospective or something, where you're stopping and you're turning around and you're taking a look and you're holding up the mirror and you're saying, Are we on the right path? What things can we check to make sure we are still moving? And then turn the ship back around and keep going. So as long as you're doing that iteratively, especially in today's day and age, it's a much better, smoother process to getting the work done.

Tim Bornholdt 19:01
How much is too much for doing that when you're in a project though? How do you balance out when a customer is like, I guess it comes down to expectations again, but if a customer is expecting to see quick, iterative progress every day, but your team needs, you know, a week to push down, how do you balance those concerns between the team and the customer?

Kurt Schmidt 19:22
Well, I think it really comes down to, again, realigning on value. That's why we spend a lot of time up front doing discovery. One of the things that we do for a lot of our applications, whether they be a mobile application or a web application, or you know, an ERP integration with Salesforce and blah, blah, blah, whatever it might be, we always come up with the guiding principles up front. And that's usually just a simple statement that says we will know this is successful when blank happens and we can measure it by blank and going on down the line, right? So we come up with this statement that we all agree on the development side, the design side, the strategy, the business side. And we check regularly. Is this still the guiding principle of why we're doing what we're doing? The Why is the most important. If it turns into the How then you're off track, and you need to pull it back on track. And, again, to your point, if expectations change throughout it, that's when you have to go back to the customer and say, Okay, it looks like expectations have changed. It looks like you want daily code deliveries versus weekly code deliveries. So I think we need to change what the format of this entire engagement is, so we're back on the same page. And let's redo that guiding principle that now says the goal is to do x versus what we had decided before.

Tim Bornholdt 20:58
That's really helpful to have that expectation up front, like you said, of having a clear vision, because that's the thing with technology is, as fast as the external technology field evolves quite frequently when you're in the middle of developing an app, your internal discoveries change the project as well. And I mean, I think every project I've worked on, besides the really small ones, but any project of any substantial size, what you come into at the beginning of the project, it's funny to come back when you're done. And you look at those initial sketches of what you came up with. And it's just completely, not completely, but it's generally substantially different. You discover so much when you're going through that process. So it is nice to have that discovery, have that statement, so you can always be aligned of we know generally where we're going and the path may wind but we'll ultimately get there if we follow the North Star of the statement.

Kurt Schmidt 21:56
Well, yeah, and on top of that, making sure that the development team is part of that discovery and they understand the why. Because too many times, people just toss things over to developers and say, There's your tech specs, there's your prototype, there's your whatever, go and make that thing. Now, the thing that people have to realize is that developers, as you know, Tim, have to make so many decisions in the micro while they're coding and while they're building, and while they're pushing things, and while they're merging branches, and they're doing all this. They're making so many decisions in the micro, that if they don't understand why they're doing what they're doing, if they don't understand what the value is of this application, what the impact is going to have on the other side of it, they're going to make some wrong decisions in that micro which will globally affect the entire project. So that's the other piece of advice I'd say is that not only that iterative process and that guiding light, but also make sure it's a full team communication that everybody understands what good looks like, why when this is done, what the impact it's going to have, what are the things it needs to do? And I think you get a better product in the end, not only from a user perspective, but from a performance and build perspective.

Tim Bornholdt 23:13
That makes perfect sense. I have one more question on the project management side that I love asking people that are technical who have kind of shifted into more of maybe a sales role or just more interacting with the client directly. I think a lot of people think tech is magic.

Kurt Schmidt 23:32
It is absolutely magic.

Tim Bornholdt 23:34
It is. It absolutely is magic.

Kurt Schmidt 23:35
Don't tell people it's not magic, Tim, they'll stop paying you for it.

Tim Bornholdt 23:39
Exactly. I'll be out of work real quick. But I think one of my biggest pet peeves with people that are so technical, I mean, I was in computer science school and I was annoyed with people who would go up to the front of the class and expose how smart they are with how these computer algorithms work or whatever. But I think when you're in the context of, like, most of the people we work with, they're not app developers. They're not people that know anything about technology. They just need to get a problem solved or something fixed on their end. But often, we run into technical problems from our side, and they don't understand why there's a problem happening. They just know that a problem is happening. And you could pretty easily look at them and say, Well, we're having this issue and just spout it off at them technically and make them feel dumb. But I don't think that's a great way to maintain clients. So I'm wondering, on your end, how do you tend to effectively communicate some technical hurdle to a client who may not have that technical background?

Kurt Schmidt 24:47
Sure. Well, I mean, I'm gonna give you an answer that might sound a little flippant, but I start by asking them how do they want to be communicated to at the beginning of the project, if there is and when there is an issue. I ask them, Do you want an email? Do you want a phone call? Do you want it to explain in technical details what's happening or what changes need to happen or what decisions you need to make? How would you want to address potential roadblocks that we run into up front? And I make the client be a part of that decision making process so that when that technical issue does and always does come up, and I have to give them a call and say, Well, yep, this API call is taking over a minute before it loads in the data in this page or something, and that's taking too long. Cool. So here's, like we discussed, here's how I'm going to report to you what the issue is and then how we're addressing it. And then here's the follow up piece to it. So, again, having a frank conversation upfront about how they prefer the communication to happen. It empowers the client to feel like they have a bit more control, even if it's over something that is over their head in terms of technology, right?

Tim Bornholdt 26:09
Yeah. And I think, from my end since I'm on one side of the table of I'm communicating to clients, you know, how do you want to be spoken to about how technical problems come up. It's great for my listeners to hear from their end of when you're engaging an app development company to build your tool for you, these are the kinds of things that you can turn around and ask them to say, Hey, how are you going to tell me that there's a problem happening? And I think I've never been asked by a client. I think everyone's just like, Oh, problems are never gonna happen with this. So it'll just be fine. But there's a lot of steps that you can take as the client because again, people think that tech is magic. And I think a lot of people feel powerless when they're in the client role. They can do so much from there end. They can direct and kind of say what they want. But they don't really often feel like they can be part of the actual development of the product. And I think that this is a key area, like you said, of engaging them in at the very beginning of the project and saying, Hw do you want to be part of this process? That's really powerful, and something you can take away when you're building your own app.

Kurt Schmidt 27:22
Yeah, if they feel like they have some sense of control, where at least they can control how the communication happens, because Tim, I've been doing this a long time. And I know you have too. I mean, you have all sorts of people that will call you at 11 o'clock at night, or they'll text you on a weekend or whichever, and they'll be like, What's going on with this thing? And if you hadn't set communication expectations up front or presented them with a communication plan, and agreed upon it, you know, I really don't have a lot of empathy for you. You've kind of done that to yourself.

Tim Bornholdt 28:00
Right. And if you're not sticking up for yourself, and saying like, this is how I need to be communicated with and then reciprocating back and saying, How do you need to be communicated with? Then yeah, that's solves a lot of problems. It's exactly why you have contracts in general in the first place. You establish rules at the beginning of an engagement and make sure that everyone's on the same page with how things are going to be done. And it's better to figure that out before there's an API call that's taking a minute to return. Because if you're in that moment, and everyone's stressed out about fixing that, the last thing you want to be doing is trying to figure out how to communicate.

Kurt Schmidt 28:37
Somebody smarter than me came up with this, but I steal it all the time. And this is how I coach the development team at Foundry is that before we deliver code, communication is our deliverable. And so every day if we're not delivering code, we're delivering communication, that's in the form of stand ups, status reports, phone calls, demos, demos internally, demos with the client. All those things, our entire organization is a communication organization first and a development company second.

Tim Bornholdt 29:09
That's a really good way to look at it. You shouldn't say that you stole it though. You say you borrowed inspiration from. That's one thing I've stolen from somebody was how to phrase that.

Kurt Schmidt 29:22
Yes, yes. I borrow a lot of inspiration Tim.

Tim Bornholdt 29:26
Exactly. I think we touched on a little bit of project strategy stuff already but I think I'd like to switch gears directly, head on into that now. And yeah, let's just jump right in. So why do I need a strategy for my mobile app? Can't I just say, I need an Uber for dog sitting, and just away I go?

Kurt Schmidt 29:48
Yeah, no, I mean, you can absolutely and, you know, if you've got the money to do it, I would suggest maybe go to a casino too, and put all your money on 57 or something. But honestly, in all seriousness, the strategy part is something that I think people start to pay more attention to over the past few years. But before, and still today, I still have people call up and say I need an app. And one of the first questions is, is why? Are you sure you need an application? Tell me what the problem is, what is the problem you're trying to solve? And once we start having those conversations, that's when the strategy starts to emerge, and finding the actual problem that needs to be solved. And is this the tool that helps solve that application?

And don't get me wrong. There are certain organizations out there from a brand perspective that feel the need to have an app because it's part of, you know, having a website or a business card. I have an app, I have a native application of some kind. I totally get that and totally understand and I totally respect that people have it. But what is the value that they're actually trying to provide? You know, and I'll steal, I'm sorry, I'll borrow. I borrowed some inspiration from another colleague of mine that talks about, how wrong are you willing to be? Right? Are you willing to go into this without much knowledge, without weeks and weeks of planning and just start putting things in front of people and seeing if your ideas are correct? Or do you need something that is fully fleshed out, fully polished and all those different things? You have very different approaches to those types of projects. So I would say in the short answer is, why you need a strategy is so you don't spend a lot of time and money and you don't waste it.

Tim Bornholdt 31:57
Yeah, I often tell people I'm probably the world's worst app salesperson, because I'm always hearing pitches for app ideas. And that doesn't need to be an app. It could be a website, or it could just never exist in the first place. Because I don't know if you're ever going to find someone to pay you for the service.

Kurt Schmidt 32:20
There's another side to that. Sorry to interrupt. But there's another side to that, which is, you know, I hear about apps that already exist, but it's okay, there's competitive apps. Can you make a better experience for people? That's great, too. Is that the focus? Or are you just trying to compete?

Tim Bornholdt 32:38
That makes sense. Because, yeah, if there's something already out there, then that can actually show that there's a market for it. And if you can just jump on top of it and make it better, that's a great way to actually build a company.

Kurt Schmidt 32:56
Yeah. Yeah, I mean, a lot of places do, right. Isn't that new new internet? Wasn't that Silicon Valley? Why not.

Tim Bornholdt 33:05
Exactly. Well and everyone needs to know if it's a hot dog or not, that's the best idea ever.

Kurt Schmidt 33:12
Oh, you know, people downloaded it. I don't know, I don't think a lot of people kept it on their phone. But why not? It gets the message across? Right?

Tim Bornholdt 33:20
That's a perfect example of a marketing reason for an app to exist and maybe not necessarily the utility of an app to exist.

Kurt Schmidt 33:27
No, no, it's about communication and messaging. You know, sometimes an app does, that other times, it doesn't need to.

Tim Bornholdt 33:36
So one thing that I was just thinking about when we were talking about why you would need a strategy for an app, and I'm coming at it as the first question being, Why do you need an app? How would you suggest somebody approach finding... So if I want to have a mobile app done, would it make more sense to come to a shop like yours or to come to an app development company and have that discovery done with a team? Because if I'm not technically savvy enough to make those determinations of, Oh, well, you don't need an app, but a responsive website would work. Or, Oh, yeah, you could build that in React Native and cut your costs, or whatever. Is that part of what you would do then as part of that strategy session? Or would you suggest that they kind of take that on on their own before coming over and approaching an app development shop?

Kurt Schmidt 34:28
Yeah,it's funny to me that like, you know, there's all sorts of ways to really broach that conversation. And the more you start to dive into what the reason is, the behavior that client is trying to get out of folks, I'm telling you, a lot of the things that we do is to make sure that it isn't an insular conversation, that you are bringing in the actual people who you want to use the application as part of that discovery session. Too many times, I see people come in, just like you were saying, and say, I want the Uber for this, or I want the Uber for that. I'm like, Great, go and find a few people that you think will use this application, and let's bring them in, and let's have a conversation as a group about what we should build and why we should build it and how we can make this the thing that lives on their home screen for the rest of their days, you know? So, honestly, it's about making the conversation not so insular, where it's just about maybe that founder or that stakeholder in a larger business. Where they're like, I've got a great idea and the light bulb appears over their head and gets all cartoony and all that stuff. It's like, great.

Now, I'm sure you've dealt with this Tim in the past, is where we've had some founders come, and they say, I've got this great idea, but I can't tell you. I need us to sign 15 NDAs and then like cut our hands and swear a blood oath, and all this stuff before I can share it with you. And those are the people that, sometimes I get it, like they're very cautious. I don't mean to say you shouldn't be cautious. But some of the ones that I found that are the most successful are the people that tell everybody what their idea is. They tell everybody and they won't shut up about it. They tell the, you know, cashier at Target. And they're constantly testing, testing, testing. Those are some of the people that I've seen be the most successful, is that they are including their intended audience in the conversation, because there's a plenty of group of companies out there that were like, I know exactly what people need, and I'm going to tell them what they should have. And those are companies like Sears and Blockbuster and now look where they're at.

Tim Bornholdt 37:03
Or Apple.

Kurt Schmidt 37:04
Well, you know, but again, that's the thing is that Apple's process does include a ton of user research as part of what they're doing. The thing is, you just don't hear about it as much because they're very good at keeping that stuff within the whole Apple shroud, you know, and everything. But honestly, it's making sure that you have those people who are going to actually use this application be a part of that discovery session, I've found to be probably one of the most fundamental reasons why an application is successful long term.

Tim Bornholdt 37:48
Well, I think that makes a lot of sense because like you were talking about with the NDA, maybe once or twice, ever. No, once or twice a week, we get people that come to us that say, I'm going to tell you my idea, but you need to sign the NDA or you need to review all my patent stuff, or whatever it is. And it's like, I think a lot of people get the idea in their head of this solves a problem for me. Or this would be a great idea that lives in the universe. But if you keep it in your head, then you bloat it out to be something massive, the whole getting to value right away. Because you're starting to say, Oh, yeah, if my thing does this and this and this and this, that'd be so cool. But maybe nobody would like the other three "and this's". And so yeah, that makes a ton of sense of getting somebody that they're actually going to use the app and getting 5 of them or 50 of them or 500 of them to actually give you feedback on what they would actually pay for and go about it that way. And having the users really steer, it sounds like you're saying, having the user's steering at least part of the strategy is really fundamental to building a successful app.

Kurt Schmidt 39:07
It absolutely has to be. You said it. You've nailed it. It's really making sure that you're being as transparent as possible and bringing people along for the journey. Because if you want people to be there at the destination, you can't just like transport them there. They'll be like, Where am I? How did I get here? That's not how it works. Having people come along with you with the journey, you're going to get the most value. And honestly, you're going to spend a lot less money and a lot less time. And you're going to have a more successful application.

Tim Bornholdt 39:48
So besides not including users at the start of a strategy session, or at the start of developing the strategy for your app, what other rookie mistakes do you see people making? And again, you can't say that they don't have a strategy at all. Let's assume somebody wants a strategy. And skipping that and also the not including users right up front, what would you say are some of those rookie mistakes when you're at this stage of coming up with a strategy for your product?

Kurt Schmidt 40:18
Well, I would, uh, I would talk about a couple of things. One thing is, you know, if you're working with a group, and maybe they have a marketing team, maybe they have a lot of personas and demographics, all those things. There's a difference about who your user is versus where your user is at, having a good understanding of where the user is at and what the opportunities are when they're in that space. Right?

And so a couple examples might be, let's talk about the Target application. You know, there used to be a Cartwheel app for coupons and then there was the Target app. And then eventually they slammed them all together and made the app just more confusing. And they were making these apps in a way that the Cartwheel app was a great app because it focused on where the user was at. It knew that you were most likely using the app in the store and not at home, because of the testing and research they did. So knowing that you're walking around with your head down in a store, when there's lots of other people, and there's walls and shelves and things to run into, they had to design the application a little differently than they would if you were consuming that just sitting at home, you know, air quotes, clipping coupons, right? So doing that research really helped make the application a much better, more successful application.

But then you go back to a company you might have heard of called Foursquare, which had a great application that was like, Wow, this is great. What we need to do is we need to diversify this application. And let's split it into two separate applications. And then the application you really like to use, we're going to rename that one. And then we're going to create this other one that kind of sort of competes with Yelp, but not really, but Google Places but not really, but I don't know what it is, but it's a thing and everybody go use it. And then people are like, What? No. And they never recovered from that decision. Because again, they took the information that they had, and there's a great book out there that I would suggest for people to read. There's a book called "How to Lie with Statistics." It's a great book, and really understanding internally what that data is telling you on what you should be doing and being able to interpret that data in an honest and transparent way within your organization. Instead of maybe having one department driving all of those analytics, being able to share that data across the organization and say, What do you think this means? What do you think this means? It looks like people are using this in store. It looks like people are not doing this at home. We thought they were doing this at home, but they're not. What suggestions do you have? Again, bringing in more individuals, more opinions, doesn't mean that, you know, you're shirking the responsibility of making a decision. It just allows you to gather more and more data up front.

So again, short answer long, you know, making sure you understand where your users are at and what that data means versus what your assumptions are around that because that's the point too I'll bring up is, a lot of people will do assumptive personas, right? Especially maybe in a smaller startup or something like that, where, Well, this is for CMOs. Okay, how many CMOs have you talked to? Well, I was a CMO a long time ago, and I know what CMOs do. And so this is what CMOs are looking for. Okay, great. So we'll make an assumptive persona around this. And then at some point, we want to go and actually test this assumptive persona and turn it into a true persona. And again, back to that point about being able to call it what it is, right? This is assumptive. We're basing it off of you, who is the startup founder, versus what the, you know, half a dozen people I could just find on LinkedIn and ask them a question about how they would really use it.

So those two pieces about the assumptive persona, and then understanding where the user is at I think, are two pieces that I see people miss very, very quickly. One other piece that I'll talk about too, is talking about technology before you figure out what the problem is you're solving. So we get it all the time. And I bet you've had this too. We've had people call up and say, Hey, do you do Xamarin? And I'm like, that doesn't sound like a solution. That sounds like a solution to create a problem. I've had people call up and say, I need four front end developers for six weeks. And I'm like, That does not sound like a solution at all. When I see people talking about the technology, you know, people say like, Yeah, I'm doing this, because the new Uber for something is the Blockchain for something, right. And so we'll hear people talk about that. No, this is like sales using blockchain. This is building Campbell's Soup but with Blockchain or these types of things. And I get it, like these types of things happen all the time where a new hotness shows up. It's just like every six months, there's a new version of JavaScript that everybody's got to use and relearn. But if I hear people talking about the technology upfront, that's usually a pretty big red flag that we have to have an honest discussion that the technology should not drive the solution. And to be honest, Tim, there's a lot of people out there that are like, Nope, the technology has to drive the solution, because my business is IoT, and it has to follow these things. Or I'm Medtronic and I have all these regulations. Totally get it. I'm not talking to those folks. But I'm talking to the people that are new to this space and have just enough information to be dangerous. When you start talking about technology before you start talking about the solution, and what the design is going to be and how you're designing to that solution, that's also, to use your words, a rookie mistake I've seen.

Tim Bornholdt 46:57
Man you sucked all my follow up questions out of the air. Because you touched on exactly what I was gonna say, was there's a difference between somebody coming to me and saying, Do you do Xamarin? Because my app needs to be in Xamarin versus my organization's databases are Postgres, so I need you to make sure that you can write in Postgres. It's like, Okay, well, that that makes sense. It's funny how much a piece of paper and a pen can actually be more effective at solving a business problem than building an entire app to solve that one problem. And I would assume you get some customers like that, where they come to you with, I need this problem solved with technology. And sometimes that's not even what the solution is. It's really you got to sit down and figure out a whole heap of other problems. And it seems like instead of having, you know, product strategist as your title, it should be therapist because you're sitting through and actually solving deep embedded problems within a company as opposed to solving like this surface level issue that might be able to be solved with technology.

Kurt Schmidt 48:09
Yeah. And that's why the term has been floating around for a long time at McKinsey, and a number of these large consulting firms, Accenture, Deloitte. They've latched on to this term, digital transformation, where it's about that changing the conversation in an organization, instead of thinking of solution first versus problem definition first. That's where, you know, a lot of mid-size to larger, not just the enterprise, but even mid-sized to large organizations really need to make a focus on is that problem definition space. Are we defining the problem correctly? Is this actually a problem? Could it be just solved by just hiring another person versus, you know, building some sort of technology? And to be honest, you know, it really depends on the business. But if you're not asking those hard questions upfront to really understand what the problem is that you're trying to solve, and really understand the problem, then you shouldn't be talking about technology at all. You know, but like I said, there's edge cases. There's companies and industries that are very highly regulated that need to follow a certain thing, or I'm an organization that's already invested a million dollars a year into Oracle or Salesforce, totally get it. We need to hook into those things because you've already made that commitment. But let's not let those things become a deterrent. Let's find a way to make them supercharge the next iteration of what your company is going to do.

Tim Bornholdt 49:56
Right on. That makes perfect sense. I've said that 1000 times in this episode, but it's true. So last question around product strategy. So let's say I go to you at The Foundry and I say, Hey, I have this project. I need to sit down and do a strategy workshop with you. I assume you get your team, I get my team, we sit down, and probably bring in some users, like you said, but let's say day one, we're sitting down. Walk me through what that would look like and what the ultimate, when I'm done with this workshop, what do I get out of that?

Kurt Schmidt 50:34
So The Foundry product design workshops are, basically they come t-shirt sized. And the reason is is on the size of the problem. There's small, medium and large. You know, a small one might be just some consultation, and some sketching and some user definition and some things just to kind of vet out what is the problem, is it a problem, and then move on from there.

The more medium sized one is much more involved where we're spending a few days with, like you said, stakeholders and potential consumers of the application. We're walking through what those guiding principles are. We're also talking through who those users are, where they're at, what their goals are. We're also looking at the competitive landscape, not even direct competitors, but maybe indirect competitors. That's where we maybe go down a jobs-to-be-done sort of approach, right? What job if I hired to solve this? Who have I hired already to solve this problem for me? You know, Oh, I'm gonna go after Uber, for example. Okay, let's understand why people have already hired Uber to solve this problem for them. And then if we dissect that we can understand what their motivations and things are around that. But the thing is is that, in the end, what you want is basically your pitch deck. You basically want everything that explains what the opportunity is, what it's going to take to do it, who's going to benefit from it, what the value is, what the ROI is, what some of the maybe larger solutions are, in development talk, features, what some of those solutions that come out of it are going to be, and then basically what a roadmap for either the next year or two years looks like. Because we talk a bit about, and we talked a bit earlier about it, about the total cost of ownership. I look at it as total cost of investment. And that's not just money. That's time, right? Because as you know, Tim, a lot of times the people you're talking with that are bringing in this new thing, they already have full time jobs. Who's in charge of this thing? Who's going to manage this? Are you taking on a second job? Or are you bringing somebody else into help, you know, take over this? Is this their new initiative? Oh, we're moving the VP of tech over to be the VP of apps or something. I don't know, whatever. Talking through those things. And we even talk about that organizational support structure that I mentioned before and that strategy around that. So that's more of the medium sized.

And the larger one gets more into service design, right? Where maybe you have all the touch points and the user journeys and the customer journeys, all those things mapped out but then you start to go deep into how are they delivering on the service in each of those touch points to the consumer. What's happening on the business side that's also addressing and supporting the needs of that customer when they're in that touch point? And it can be everything from, you know, supply chain discussions to how a point of sale system works and a waiter or waitress needs to, you know, address an issue and how they record it in the system to an HR person that's dealing with an HR issue. What other things are they doing internally? I want to make sure that we're not creating a solution to create more problems. So those are big parts of what comes out of it. It's usually, what I look at is, it's the proof that we should actually build and design something is what it is. That's what you'll get coming out of those sessions.

And, you know, the other thing that's different a bit about Foundry is that we're not a dev shop. We're a product design company, a digital product design company. So we don't have an hourly rate. You get the whole team, you know, so when you're doing those workshops, it's a fixed cost, and you've got a product, digital product designer in there. You've got UX. You've got senior engineers, you've got business strategy. All of that is part of that one package deal. It's not, Oh, I need a few more hours from this person or a few more hours from this person, so the cost is going to go up and there's going to be a scope change or a change order, or whatever. That's not how we work. So it's all encompassed, you buy a team that also helps you get to that solution.

Tim Bornholdt 55:27
That's awesome. And I would imagine for especially people that are listening to the show, I mean, we have people that are in organizations, but also we have a lot of people that are with startups. And I would think even somebody that's in a startup type situation with being cash strapped and everything, I bet it would still be an incredibly good use of money to go through a session like this. So that one, you at least have real professionals validating the idea and making sure that it is something that's viable and can do well for you. But two, it's getting you on that right path so that when you do decide to pull the trigger and start developing it, and you take this to a dev shop, that you're able to speak a lot of the same languages and get things going quicker than if you just kind of jumped right in with a bunch of developers and you didn't really vet the idea and have a strategy for how you're going to get across the finish line.

Kurt Schmidt 56:21
Right, exactly. And that's why we make sure we have some of our senior engineers as part of that, because whether or not we end up being the implementers or not, we need to make sure that engineering is representative in those discussions. And so, to that point, it's a fixed cost, it has this value, it gets you this ROI on the outside of it. And a lot of times people in an organization will use that deliverable outside of that to start socializing internally either with their bossesor with the people across departments or the people that they manage to start socializing and seeing this is what the opportunity is, this is what we want to do. And it helps them start to build a reason for that investment, and then back to the startup person, being able to vet all those things, and then take that and start socializing it and showing people, this is what the app does. This is who it does it for, and all those sorts of things.

And then the next step out of those workshops is basically building a prototype. And when I say prototype, again, it's not code. It is a clickable prototype that people can actually pull up on their phone or their browser or whichever, and be able to click through maybe one or two journeys to get a good idea of what this thing does and how it solves that problem for them. Again, being very iterative, because as you know, Tim, and I think you mentioned before, paper and pen is pretty cheap. Code is expensive. And so the more you can do upfront to make sure you're validating and solving those things upfront, will get you a much better experience through the development process later, but, you know, you've got to spend the time to do it. So it's a lot of fun. Honestly, I get a lot of people that say, What's the "aha moment" I'm gonna get out of this workshop? Well, the aha moment is the problem and solution you thought you had are not going to be what you left with. That's the aha moment.

Tim Bornholdt 58:42
And when you go to socialize with everyone too, I'm sure you can supply them with a fistful of NDAs so that they keep that idea nice and locked down.

Kurt Schmidt 58:54
Absolutely. Fistfuls of NDAs. You get an NDA. You get an NDA.

Tim Bornholdt 58:59
You're the Oprah of NDAs. It's Oprah that we didn't ask for but it's the Oprah we deserve.

Kurt Schmidt 59:03
It is the one we deserve. I think that's pretty close. Oprah? Batman? It's interchangeable. Yeah, no, you're absolutely right. I mean, there's a big part of, you know, coming together as a group and really, really trying to solve a problem, because as you know, Tim, there are people out there that just want to build stuff. And that's great. Just go build stuff. But then there's other people out there that want to solve a problem. They have to solve a problem. They see the opportunity, they see the problem. And so yeah, maybe their first inclination is an app. Oh, yes, an app can solve that problem. Great. Let's talk and let's go through it. Let's figure out what the problem is, why it's a problem, how we're going to solve it for people, and then what that execution of that solution needs to be. It's a super valuable process. Honestly, we don't charge enough for it, but because of the value I think it provides, but it's a great time. Like, honestly, we have a lot of fun with the people in the room. It's a great experience. And again, back to what I talked about, we do a lot of service design. We've workshopped our workshops to make sure that they are providing the amount of value that we feel that they need to be providing. And we do a lot of customer follow up afterwards to ensure that they felt really good about those things. And to be honest, we have a money back guarantee for those workshops.

Tim Bornholdt 1:00:42
Oh, wow, really putting your money where your mouth is then with it?

Kurt Schmidt 1:00:45
Well, again, it's about providing value and if neither of us get value out of the workshop, what's the point? It doesn't do anybody any good and the company that we want to be and the company that we want to build and the people we want to work with, you know, we all need to be aligned and we all need to understand why we're doing what we're doing.

Tim Bornholdt 1:01:13
Again, that makes a lot of sense. Kurt, this has been, for me, it's been a really great time. I hope you've had fun on this episode as well.

Kurt Schmidt 1:01:25
Yeah.

Tim Bornholdt 1:01:25
Do you have any parting thoughts you'd like to give? Maybe put in a plug for where people can find you at the Foundry and any last minute tips you might want to throw out for anything with project management or strategy?

Kurt Schmidt 1:01:37
Yeah, well, a couple of quick tips is don't waste your time looking for tons of different types of project management tools, just start with a spreadsheet and then go from there. You know, a lot of people hem and haw like, what to-do app should I have and how should I manage this? And JIRA, Trello, Asana. You know, start with a spreadsheet. Make sure that you got communication down first before you start throwing digital tools at things in order to solve a problem. That's one thing I can say I've learned. In the beginning, I tried every to-do list and I tried tons of different project management tools. And it basically all was avoiding the real thing I needed to focus on is better communication. So, focus on communication first and making sure that you're mastering that or you're working towards mastering that. And then come back and layer on tools. Again, test your communication, and the tool will appear for you every time, so that's my tip.

And then on the outside of that, you can find Foundry at FoundryMakes.com. And then my podcast Schmidt List, which you know, I started over a year ago. Basically I created a little list of individuals and folks and roles that I really wanted to talk to and learn a lot about. I created it. And then, you know, over some wine, some friends and I came up with the idea of calling it the Schmidt List, which, technically it is, but it's kind of tongue in cheek, a little funny, you know, asking people if they want to be on my Schmidt List. But it's been great. So that's Schmidt-List.com. Or you can find it on Apple Podcasts, Google Podcasts, Spotify, iHeartRadio. It's all over there. And basically, if I were to tell you, it's meant to inspire people who are leaders in technology and design. And I would say the secret tagline is how to influence without authority, which was kind of one of my original titles, but I thought that just sounds a little like forced, you know. So Schmidt List is more fun because it is a casual conversation, much like this one. And, yeah, you can check out all those things.

Tim Bornholdt 1:04:00
Fantastic. Well, we'll link both in the show notes too so people can find it right there. And thank you so much for joining me today, Kurt. It's been a real pleasure.

Kurt Schmidt 1:04:08
Well, no, Tim, this has been great. Thank you so much for taking the time. I've been enjoying the show. So keep up the good work. And yeah, no, thanks for the opportunity.

Tim Bornholdt 1:04:24
Our guest today was Kurt Schmidt. You can find more about him at KrtSchmidt.com. That's Kurt without the U, so krtschmidt.com or by looking up his podcast the Schmidt List on whatever platform you're listening to this show.

Show notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing Hello@constantvariables.co. I'm @TimBornholdt on Twitter and the show is @CV_podcast. Today's episode was edited by the Jordan Daoust.

This episode is brought to you by The Jed Mahonis Group who builds mobile software solutions for the ondemand economy. Learn more at jmg.mn.