40: Human Centered Design for Simple Products with Amber Christian of Wonderly Software Solutions
Published July 7, 2020Run time: 01:05:46
When it comes to design, simple is not bad; simple is good. Amber Christian of Wonderly Software Solutions has worked really hard at making her product Bella Scena simple to use, and she joins the show to discuss a design process few people are talking about and even less are doing: Human Centered Design. She shares some practical applications of Human Centered Design, how continuous integration (CI) can save your developers tons of time, lessons she learned in the ERP world, what to do when you receive contradictory pieces of feedback from your users, and the pros and cons of bootstrapping a business.
In this episode, you will learn:
- Why you want to hear people call your “baby” ugly
- How to convince management on agile methodology
- How investing in design can reduce customer support
- How to consider criticality, repeatability, and ability to source when determining what development to keep in-house and what to outsource
- Why owning your software subscriptions can mitigate risk
This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.
Recorded May 28, 2020 | Edited by Jordan Daoust | Produced by Jenny Karkowski
Show Notes:
Episode Transcript:
Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non-technical look at all things technical. I'm Tim Bornholdt. Let's get nerdy.
Today we are interviewing Amber Christian of Wonderly Software Solutions. Wonderly embraces new ways of building technology through human centered design. And their first product is called Bella Scena, which is an awesome tool that helps you build a process around your meetings. You should all pause the episode and go check it out right now because it is really cool.
In this episode, we discuss the origin story of Wonderly and Bella Scena, what Human Centered Design is and some practical applications of it, tips for not taking customer feedback personally, continuous integration, or CI, and how it can help save your developers tons of time, lessons Amber learned in the ERP world, what to do when you receive contradictory pieces of feedback from your users, (How often does that happen?), how Amber built the tech team behind Bella Scena, and the pros and cons of bootstrapping a business.
So without further ado, here is my interview with Amber Christian. Amber Christian, welcome to the show.
Amber Christian 1:21
Thank you so much for having me today, Tim.
Tim Bornholdt 1:23
I'm really excited. I mean, we just spent like 20 minutes of the best podcast material that you've ever heard, without recording any of it. So hopefully, now that the record button has been hit, we'll be able to, you know, keep some of that gold going here. So I'm really excited to have you on the show here today.
Amber Christian 1:43
Absolutely. I'm excited to be here as well.
Tim Bornholdt 1:46
So I want to start, why don't we start at the beginning? So everyone's on the same page here, let's hear your origin story.
Amber Christian 1:54
So I'm Amber Christian. For those who don't know me, I'm the founder of Wonderly Software Solutions. We're based in Minneapolis, Minnesota. I've actually been in technology for 20 years. And about three years ago, I realized there was a problem. Bad meetings or unproductive meetings. Oh, have you been in one? From that laugh, it sounds like you've been in one or two in your life.
Tim Bornholdt 2:20
I only see it on TV. I've never personally been involved in one myself; all of mine are flawless and very productive.
Amber Christian 2:28
Absolutely. So after I was a consultant for many years, and I did SAP implementations, and even do some of that part time still, as well, and one of the things that I noticed in a lot of large organizations is we will run into a lot of meeting inefficiencies. And it's normal inside small and large organizations. And I went hunting for a product to help manage meetings better, to track the follow ups, to actually track your notes and all those kinds of things. And I couldn't find anything that worked the way I thought. I had some ideas around what I was looking for, and just there was just nothing on the market for it. And it was at that point that I crossed a mental chasm and decided to actually go build software instead of implementing someone else's software. So that actually is what started the journey after a long career in technology, going, Okay, well, it's time to go build it.
Tim Bornholdt 3:28
Well, I'm glad you made that leap. Because I think I was even looking at your website before this and seeing that calculator that you have on there, everyone should go and check that out, where you plug in the average hourly rate of your employees and the average contractor rates and then the number of people you have in a meeting and then how long that meeting goes. And it's like, it's pretty easy to burn, you know, a few hundred bucks and you don't even think about it that way. You just think like, Oh, we're all, you know, just sitting in this room and not getting anything done. But I mean, it's a real problem for a lot of businesses.
Amber Christian 4:00
It's a multi billion dollar year problem, and it's a growing problem. So sometimes people would say, What's your total addressable market? Like, okay, I'm appalled at talking about how big it is. You see, I've seen numbers anywhere from 30 billion to 100 billion dollars a year in lost productivity in the US. They're like, Well, that's not exactly your total addressable market. But as you talk with people about them, like I feel silly even just talking about the numbers; it's really bad. It's a huge issue.
Tim Bornholdt 4:30
Oh, yeah. And if people ask that, I would just turn around and say, Well, this meeting's case in point if you're talking about something that's not being productive. So how did you solve it? Talk a little bit about the solution then.
Amber Christian 4:46
So I made one of the early mistakes that a lot of people make when approaching software and solving problems with them. So first thing I did, I actually had a prototype of the product and I built it based on what I knew of the problem. And I took that prototype and I showed it, this is the thing that saved me, I showed it to about 12 different people. I did walkthroughs with those 12 people. And at that time, they gave me feedback. And the feedback list was about as long as your arm, like holy smokes. And I realized that I had this prototype, I had this amazing set of feedback, but I couldn't figure out a clear path to the market at that point in time. And I think that's a common challenge a lot of people have is, Okay, well I just solve it and I go build this thing and go, here's my thing, use it. Right? I realized at that point, something about the problem, I was missing something about the problem.
So from there, we embarked on a design journey, actually using Human Centered Design. I didn't even know it was called that till a year in, let's be super honest. But it was really about having conversations with people to understand the pain points and the problems we were solving and how we were going about solving those. And so really deeply working with people on the product before it was ever built, instead of actually building a product and then having people try it. So that was a process that actually took about two years. And I like to be super honest with people. I made this process up. So when I talk about this, it worked really well. I did make it up. So if you're like, Oh, is there a book written? No, my head and 20 years of software implementations.
So what we did at that point, we built this first MVP. And I realized that figuring out how to get to market and my pricing, I couldn't figure out how do you price this thing as well. I actually worked with a pricing consultant. And what we worked through at that time, we went back to the drawing board as part of the conversations. And we started over from the problem set. So we actually did a series of interviews and at that time, it was eight interviews. And we had a structured series of questions that we asked each person, every single person got asked the same set of questions, super important for drawing conclusions and making sure there isn't bias and other things at it. So that was really important. So we did these interviews with eight people. And those eight people, I made sure we had a balance of men and women. We had 50% men, 50% women, and then we also balanced generationally as well. And this was important because we got different types of answers depending on sometimes which generation you came from, how technically savvy were you. We had different things emerging from that.
So after we had all of that information, we had a much better understanding of what the themes were for the problem that we were solving. And then we could use design to do the next round. So the survey part was super helpful at uncovering all the places that people were experiencing issues. And then we applied a couple of months design to that, and put together what we thought our solutions for the issues are. So that was the next phase of it. At the end of that phase, I did... Oh, this was a challenging process. We did reviews with like, I think it was between 30 and 35 people. If you ever want to, as a founder, you know, we're in love with our products, right? You've seen that once or twice? You ever want to fall out of love with their product or get real objective about your product, show it to, you know, 30 people and walk them through it and gather feedback. They will beat the bias out of you real quick, really fast, but they also help you understand what's valuable and powerful about what you've built. So they give you a lot of really, really helpful information. So we did this review with the 30 odd people and collected all this additional feddback, then we iterated on the design again, at that point, because they told us places that the design didn't work, didn't solve the problem, big things we had missed, or if the design was problematic for some reason. And that was a really powerful part of the conversation. We pulled several features out because the way we had designed them was problematic for people.
And I'm waiting for you to say, What do you mean problematic, Amber? Like, what does that mean? So I'll give you, I'll give you an easy example. In this round of the product, we had used a color scheme that was red, yellow, and green. Do you know why red, yellow and green might be a problem?
Tim Bornholdt 9:52
Well, I can think it would be like stoplight in a sense. Am I on the right track with that?
Amber Christian 9:59
Yep. That was the idea. And that was actually a problem because, first of all, there is a percentage of men that are colorblind, red green colorblind. So if you just color code, they don't know, unless you have like a secondary way of identifying things. So that was the first problem. The second problem was over 10% of our feedback came in and said, if anything was actually red that was near their name in the product, they personally felt like they were a failure. Hmm, like, What? Wait. So if there was an overdue item, and we turned their name to red, they're like, Well, I'm a failure. Whoa, whoa, whoa, that's not what we were trying to say at all. So that's the power of feedback, you can actually discover that you had a wonderful intention around your design, you thought it was really helpful, because that's how you process the world. You have to show it to other people to see how they process the world, and how they process that design.
Tim Bornholdt 10:36
Personally, I've been through a lot of those meetings, and I find it, like you said before, very humbling, and and you get kind of the bias beaten out of you. Because it is just people pointing out all the flaws within your software. How do you as a founder not take that personally? And how do you actually then turn that around and try to find solutions that help address the concerns that are brought up to you?
Amber Christian 11:42
Well, the first part of it is the way you frame the questions when you do the review. You're asking about how people are interpreting things or what things mean to them, or what they would see out of things. And so part of it's the question design that gets you out of it being about you personally. So if you set the questions up properly, that helps. But yeah, it's going to be painful because they're going to point out all kinds of things that they either don't understand that you thought were clear, or that they hate, or that they love. This is the other side of it, because we got plenty of that too. We have plenty of, holy smokes, this would be amazing to have something like this in place. So I really looked for a balance in that feedback. As a founder, I said, Okay, yes, it's very difficult to process emotionally. You know, it's like, oh, what if they call the baby ugly? But you need them to call the baby ugly now before your code is written. Because it's so much more expensive to rebuild it all later.
Tim Bornholdt 12:54
Yes. Yes, it's much, much better to fix things when it's a Photoshop design as opposed to a fully realized app.
Amber Christian 13:03
Yep, exactly. Exactly. So for me, yes, it was really hard. For me it was actually more exhausting. I'm an introvert. So it's actually just more exhausting getting through all the interviews and having so many conversations because I did it over like a two week period of time. So I was pretty worn out by the end of doing that. But the information that yielded was really powerful. And that's what I held on to even though sometimes I thought for sure people would love that and no, not so much. And I was so grateful, though, because if they're going to raise problems, they probably weren't the only person that was going to experience it. Right?
Tim Bornholdt 13:43
Yeah. And it's so hard to get feedback. A lot of times too, when it's out in the wild, you know, you get to the certain point where people are finding your product and kind of doing everything self service. This is a little bit further down the road. It's harder to collect that feedback. So I would think that it's a lot nicer when you can actually collect that feedback, talking face to face to somebody and getting it early on.
Amber Christian 14:07
Absolutely. And even at that point I did face to face and I did conference calls as well and screen shares and all that kind of stuff so that you don't literally have to do it in person. You can actually do it over the over the computer as well. There's plenty of technology to make that work from the tools that actually build the software itself, or I mean, build the UX designs itself to, you know, all your conferencing and other technologies.
So once we got through that phase, then we went back to the designs again, right? Got a whole bunch more feedback. So people think, Oh my gosh, you ever gonna build this thing ever? Right? It was a process to get through it. And then we actually iterated on those designs. And then we had some folks actually test them. And there's a couple products I'm going to throw out there that if folks have always wondered how can you actually capture feedback from people. We did click through prototypes. And this is something I would recommend for new features and to have people try things out. You can do it with new features, you could do it with entirely new products you're building. Either one works. So a product we use was called Maze. And it allowed us to do click through prototype testing. And there's several other products I think on the market that allow this as well. And then we coupled that with just a Google Form of additional questions that we asked people so that we could gather additional information from them.
So we would have them click through the exercise. The product was Bella Scena, which is, it helps you create unmissable meetings. So we would have them test various aspects of the meeting process or various aspects of creating a to-do for your to-do list and then seeing how well could people complete the exercise based on the design we put in front of them. Were they able to complete it? Where did they click on things? Because in a lot of cases, we had more than one way to do things. So we wanted to understand how that audience was then interpreting our designs as part of the process.
Tim Bornholdt 16:14
That's so cool. I hope that the founders are listening to this and taking this to heart because I do find that the more people take a human centered design approach, and actually go out and do the painful thing of hearing people call your baby ugly, that that turns into a much better product. And it's one of the coolest things about software that you can put something out there and if it stinks, you can change it and you can change it pretty rapidly and quickly. Which kind of leads into my next question. We were talking again before we started recording about continuous integration and how there's been, you know, during this time of COVID-19, you've kind of doubled down and reinvested into the efforts that you're doing on that front. So I would like to kind of pivot and talk a little bit about basically what is CI, and how you're using that to speed up adding in new features into your software.
Amber Christian 17:10
So continuous integration has been something that's been on my goal list for a very long time. And what I wanted to be able to do is, I asked myself the question of, Okay, so it's one thing to get your MVP out the door. And then done. You've just reached the starting line when that first project is out there. It's like, it's not the end. It's actually the beginning. Now the products out the door. Now you have, how are you going to get bugs fixed? How are you going to prioritize new features? What are your deployment schedules going to look like as you start to deploy new features? And there's a whole new set of processes that come into play, because there's the wild card of support or people find things that break or other issues and how are you going to kind of walk through that process?
Well, the way we were doing it is we were actually originally doing builds at the end of each day. So the developers would work all day on the code and then would do a deployment and a build. And then I would get several features to test. We did it that way for a long time. And that was okay. But that meant it was kind of, well, it was a lumpy process is probably the way to put it. You get, here's a whole pile of stuff that you have to look for. Right? And if there was an issue with something, you're digging through the code to find that issue. And so from an overall management perspective, you know, I didn't know what time of day something might be deployed. Or if we had to try to rush something through and fix it, we totally disrupt the processes, just kind of clunky, inelegant. And I wanted a better way to move features through. Because I said, Okay, once the products in the market and we start to deploy features, first of all, there's going to be bugs that I need to move through the environment quickly, because bugs happen, right? And so we'll need to be able to deploy them. And bugs don't ever happen in your software, do they?
Tim Bornholdt 19:13
Never once. No, I've never had an inefficient meeting and I've never written a bug either.
Amber Christian 19:21
That's the reality is you go, Oh! Or something got upgraded or changed and something broke and you're like-
Tim Bornholdt 19:29
It's not my fault. But it is your fault. You still got to fix it.
Amber Christian 19:32
Exactly, exactly. There might be slight variations between browsers etc. So with continuous integration, you say, Okay, I want to be able to deploy features a little bit faster. And so we use a product called Bit Bucket because I use Atlassian JIRA product for project management, and they integrate really well. But there are other products. GitHub, I believe, does this as well. And some of the other products do this as well depending on what your tech stack looks like. But what I wanted to do is be able to deploy features a little faster. So now what we do is we're able to deploy the features individually, and we do our builds as those are being deployed. So we actually are doing a few a day as we do deployment to our development system. So I might get a feature early in the morning, another feature a little later in the day, as things are being worked through. And it has made the whole throughput that much faster than having to wait to the very end. So it's become much more, it's actually much more like a sprint, you know, as I talk about managing with agile, because you're really running those features through faster. So that's one part of it is just some infrastructure to make that process smoother and faster. So now it's more clicks of a button to line things up, and then to actually have transparency back to your project management system. So I know which feature it was, and it's tied into our project management system. Oh, this feature is here, and here's where it was deployed. So transparency was really nice. I didn't have it at that level before.
Tim Bornholdt 21:06
That's got to be so nice that you have that level of transparency. And then I'm really glad that you brought up agile because when we were talking before you would mention, it kind of took a full philosophical change in the organization; it's a big mindset shift, right? Like, if you're used to delivering software, you know, once a day at the end of the day, and it's lumped together and you just do it like that, you get used to that rhythm, and then switching to a continuous integration environment, you know, everyone has to buy into that process. So is there similarities with organizations like, you know, when you go to agile, it's a similar thing, like you have to move from this mindset of either waterfall or however you were doing it before into, we're gonna chunk up work into sprints, and we're gonna calculate velocities and all that fun stuff. Was it a similar hurdle to get buy in from the entire team to do CI?
Amber Christian 22:04
Not in the least, they were actually delighted.
Tim Bornholdt 22:07
Nice.
Amber Christian 22:10
Yes. And so I do a lot of that project management and the analysis work and I have the technical team and they're like, no, this would make make my life easier. I love this, actually. So no, I had no buy-in issues. And part of it was, you know, you want to be able to bring people in to establish processes, not, Hey, I do this one-off build on my machine, and then I deploy it. Oh, my scripts broke, or, Oh, you know, somebody's not available, or, Oh, we want to go add to our staff. And now we got this clunky process that's hard to set up. And so instead, it's much easier to add people. We have a prescribed process about being able to check in those features and then be able to deploy them. It's much smoother from an overall process perspective. So no, we really didn't have challenges on the buy-in. I think the biggest challenge was getting the product manager, me, doing it.
Tim Bornholdt 23:10
That's a real thing. I was gonna say it probably wasn't difficult for your team if you were the one with the edict to come down and and do that because usually it's developers that are saying, Hey, our lives would be a million times better if we spent 35 hours to reconfigure everything. And then going forward, you know, it's so much more smooth. It's got to be a lot harder for the developers to convince management or whoever that you want to go that way. Going the other way, yeah, it makes sense that it was a lot more smooth.
Amber Christian 23:43
Well, I could just mentally add up the time for how long it would take to do the deploys. And now it's a matter of hit the button, they go on to their next work and it takes you know, six, eight minutes and then something actually does the deploy. Okay, I can already do that math. If they had to sit there and babysit that before, okay, six to eight minutes. Okay, we do several releases a week, was longer when we had a whole bunch of features, right? So a little quicker with the smaller feature sets, it's easy to generate that ROI math.
And so I'd tell you, if you are a developer in that position, and you're trying to convince management, what you should do is you should measure the amount of time that it actually takes you to check those features in and to manage that. And the amount of time that you spend managing those deploys, actually measure it, time it out over a period of days and weeks, because that's going to tell you how much more efficient you could be if you were checking it in. And then the case is, Okay, well, the 35 hours, but it adds to this length of time for the ROI. And so for me, yeah, it was a big investment. But it's already hugely paid off in our ability to deploy faster. We've been able to do multiple releases to production in a short period of time. So I'm a little bit like a kid in a candy shop.
It became so much easier. And that allowed me as a business to be more responsive. So there's that part of you that's like, Well, my actual time. And then also, what's it worth to be more responsive to the customer, to be able to move things through our infrastructure faster. That's the other side of the conversation. If you're trying to actually get your manager to go, Yeah, you can take those 35 hours and actually work through that. So that's one piece of it. But there's another piece of this that we have to talk about as well. And the other piece of it is your actual code base. And what you may discover when you go to do continuous integration is you actually code a little bit differently for continuous integration. And you can probably even speak to this better than I can. You have to think through the way you build your components, the way things are actually built in a little more detail, a little differently than you do if you're just doing all manual testing. You want to talk about that at all?
Tim Bornholdt 26:13
You're the guest. I want to hear how you guys address that.
Amber Christian 26:19
So that was an interesting one. And totally not that there's anything wrong with either approach. It's just one's a little different than the other. So we actually are now working through. What we're doing is we said, Oh, okay, we drew the line and said, Okay, new features. We have kind of a new design philosophy in that code base. And so we set them up in a certain way to make automated testing, the other side of continuous integration, make automated testing easier for us so that we can have code based tests for that. So we do that with new features. And then you go, Wait a second, what do I do when I have a whole bunch of stuff already. At some point in time, you're going to be refactoring your code base. At some point in time, you're going to be improving features, redefining features, adding to things. And at that point in time, you go back, and when you go through that enhancement process, you rebuild your code. And you do that in the style that's needed for continuous integration. So it's a little nerdy technical, but that's how we're doing that. And then I'm looking at some products that actually help you kind of look at your code base and look at code coverage and some of those kinds of things that will add up in the longer run so that I can see, you know, how much do we have automated tests for versus manual tests for.
Tim Bornholdt 27:39
That's like a huge thing also for especially startups. When you are just proving out your product and you're in that early stage, the last thing you're thinking about is writing tests and making sure that your code all still integrates with itself because you don't know what you've got really yet. And you don't know if you're going to take whatever feature you built and just rip it out because someone, again, called your baby ugly, so there's kind of less incentive at the early stages of a company to go through and have robust testing in place. But the sooner you do come back and find, like you said, get code coverage, meaning you've got tests that are testing all the different aspects of your code base and being able to go through then, if you have a test that goes through and says, Okay, when I click on this button, this window should pop up with this text in it, and it's either a thumbs up or a thumbs down.
And that's how continuous integration works really well is you have a series of these tests that go through and when you make changes to it, it compares it to those tests that you've already written. And if it passes 100% then it pushes it through and it deploys it and away it goes, and if it fails, it comes back and it says, Here's the three things you did wrong. And then in the instances where we have products that are in kind of an automated environment like that, that's so nice because you might think, you know, especially the bigger the product gets, there's no way you can manually test everything and make sure that it works all the time. It would just take way too long. So to have a computer go through, like you said, six or eight minutes is a pretty decent amount of time to go through and just do all that stuff, where it would take a human, you know, a couple hours to spin up it, fake users and fake data and all this stuff. There's a whole mess of benefits you can achieve when you do go through and take the time to set up all your tests. But it can take a while if you're going from an environment where you were manually testing everything to now automated. It does take some time to build up that code coverage like you said.
Amber Christian 29:45
Yes. And I brought some of my philosophies, even around testing, I brought those over from the ERP world in how we thought about it. And so even as we've talked about it, you can spend a lot of time even just nerding out on the whole testing subject. It's extremely difficult to get really good end-to-end automated testing, especially when there's third party components involved and there's people sending things out or data is going back and forth. And so I've borrowed some concepts for some of our early testing from the ERP world. And that's how I'm approaching it. It's a little different. People are like, Oh, I'm supposed to spin up entirely separate environments, and run all these tests, and then delete all that data. And I'm like, Naw, we're going to do that a little differently. In the ERP world, we don't do that. You don't have that luxury, right? When you're talking about an enterprise resource planning system, you're talking about the backbone of your financial systems, your sales processing systems. You don't spin one up. No, no, they're huge, right? And so in that world, we did a lot more of that, the integration and the end to end tests, and when we would do testing automation, we would create fresh data. In those cases, we would run the cycles periodically, whenever we needed to run the cycles. But we would actually go ahead and create data. And that's a little different then where someone who is pure on the, Oh, I'm going to completely spin up the environment, add the data, and then delete all the data and it goes away and said, Yeah, I need to quit doing that. So my approach is a little different than saying, No, we should. Actually it's okay if we create some data. And if we need to go back later and do routines or things to get rid of it, that's fine. We need to be thoughtful about the way that we create that data. And maybe things are created based on variables based on dates, for example, so that the current date is always used, right? So you now know you're not using some fixed type things, but you can actually make it a little more dynamic with that information that you're passing in. So I actually thought a lot about, Okay, well, how do I want to do it? I'm taking what we did in the ERP world, because it worked really well. So why not use it over in this world because actually simplifying what we'll need to do as we continue to build up tests as well, so it's a win-win on both sides.
Tim Bornholdt 31:58
Oh, yeah. And I think a lot of times when you're trying to be a startup founder, it's hard to find that line sometimes of what are we trying to - I hate the word "disrupt" - but that's like, what are we trying to innovate on? And what are we trying to build that's new? But you know, not everything in the world needs to be blown up. And not everything needs a radical transformation. It's like, you can find the concepts that have worked for hundreds or thousands of years. And, you know, just like if you hear the quote of standing on the shoulders of giants. That's exactly, again I say that a lot in this podcast, but I think it comes back here to where you can take things you've learned in other industries and apply them so that you aren't wasting time and not having to try to reinvent the wheel all the time.
Amber Christian 32:45
Mm hmm. Absolutely. I borrowed a lot of things from gasp the SAP industry. A lot of ideas on how we did big ERP, people are like, Wow, this is a nice process. I was super insistent on having a separate development versus QA stage and production environment. And insistent. There was a certain point of all of it where I was like, No, we will absolutely have three environments and people were like, Really? Interesting. She's really a stickler about this. I said, Would you like to know why you always have three environments? Because a lot of people are used to a dev and a prod. I hear that a lot in the web world, Oh, yeah, we have development and we go to production. I said, But the staging system is where we would run all of our end-to-end tests. It's where we would do product demos for sales. And you want an environment that's not being constantly changed if you're doing product demos and other things. And so by having that separate QA environment to be able to do that, that's where I can do demos. That's where I can do end to end integration testing, make sure everything works. That's where I do regression testing. And then development is, it's a little looser, right, for features being deployed faster. Things might break in development. We don't want things really breaking in our QA environment. So I also had kind of that philosophy. But that came from the ERP world, because that's what we did there as well. So we always had a dev, QA and prod. So that was another concept I borrowed that has saved me more than once. It's like, Oh, we accidentally deployed and took dev down. Oh, sorry, for your demo, to the sales people. You know, and you never want to have to say, Okay, developers don't change anything. I'm doing a demo today. It's really important. That's just annoying. You don't want that conversation. It's like, no, just put me in QA. We don't deploy to QA until we're good and ready, right, in our deployments, but, dev, have at it. Release features as they're ready, then we can figure it out. That way everybody gets to stay in their path and stays most productive. And then you all come together in the end when things are all worked out.
Tim Bornholdt 34:49
Different companies have different philosophies around testing and automation and CI and all of that and, yeah, we more frequently than not at the startup stage just have like the dev environment and a prod environment. But there are more often than not times where I find myself being like, we should have a QA environment. And as we're adding in tests and things like you, you find when you hit those limits really quick. And usually that limit comes, unfortunately, when you do have a demo for an important client, and a developer decides to deploy something that completely breaks the website. You're left showing off a PowerPoint slide or something, which is not ideal.
Amber Christian 35:29
Exactly. And we've even had that happen where I was like, Oh, something got deployed. Well, that broke. Well, that's okay. Or somebody couldn't get to it right away. They're like, Oh, is it a huge issue? I'm like, Nah, get to it in the next day or so as you're dealing with other stuff. It's not. Because I'm doing my stuff over here in QA. It's the problems you prevent from happening. You know, when you go through and spend some time on these processes, and the longer I'm at this, the more I'm reading, realizing the more time and sort of planning I put into laying some of these processes out, the less problems and the less fires that pop up all over the place. Because they just don't. They're just not an issue, because we set it up in that more structured manner.
Tim Bornholdt 36:17
Yeah, that's it. That's one thing I've been working through with our company, because we have, traditionally we've basically just been myself, my business partner, and then we've hired contractors to help us get projects done. But as time has gone on, we've added on our own employees, and it's, you know, getting to the point now where we've been needing to focus on our processes now that we've got peopl. Cause you can't really boss around contractors all that much and tell them you have to do this, this and this. They'll, you know, they don't have to, right, but now that we have employees, we can actually sit down and say, Okay, as a team, what do we believe in, what's important, and start building some process around that so that we can all be pushing forward at the same pace and doing some of these things that you couldn't essentially do if like you're trying to get a ragtag team of contractors together to put something together. If you actually have your own employees, then you can focus down and just get those processes in place so you can move faster.
Amber Christian 37:14
And I found that a lot of it comes down to incentives too. Like, I've been able to successfully work with contractors to do whatever process, really. And a lot of it was the structure and the incentives and making sure that everybody's winning. I think that's all part of it, too. So you look at continuous integration, and like we talked about for developers, like, if I follow the process and check it in that way, I win because it's that much easier. And it's that much faster to move things and that much more likely to give me more things to work on. So that's a huge win for me to actually want to follow and do those processes. Where when it's always you know, I'm changing this feature six ways to Sunday, this way, this way, this way, this way, all the time. That's not very rewarding. And that's the other side of this that I think that's really interesting too. And I've had a lot of feedback throughout this journey from developers that it's been really interesting to work on this product. Because a lot of times, you know, we build things, and it's not constantly changing. It's not like, Oh, now it's this way. Now move this button here. Now do this, change this. Not really, because we've spent a lot of time working with customers through the kinks of things ahead of time. And it means that we've had a pretty stable product.
So the other side of this whole human centered design process and then continuous integration, being able to move things faster, is the customer support side has been last. And that has been a really interesting outcome. I think it has to do with, I don't know how I might, not even sure how I could measure this yet. But what I've noticed is once people get up and running on the product, we spent a lot of time investing in the UX and so maybe a question here and there, but the support load has been pretty light so far, which has been really nice. So I'm trying to draw the line back to, Okay, what did I do so I make sure I'm always doing that in the future as we grow, and of course, there's always improvements that you want to add your product, like we want to add a lot more tutorials and things embedded in the product to make it even easier and things for people. But investing in that design, and it being a simpler design for people, has also reduced our support. Anybody can build a complicated product, right?
Tim Bornholdt 39:40
Everybody builds complicated products. I think like you were gonna say, it takes a lot to build a simple product. There's so much that goes into that.
Amber Christian 39:50
Yes, and I had to learn too, one of the things as a founder that's also been very interesting. Simple is not bad. Simple is actually good. And when I would go through, and I would do my product demos, and invariably, the person would say to me, Wow, that's simple. I thought it was gonna be a lot more complicated than that. And I'd say, I spent two years making it simple. Yeah, working really darn hard to make it simple and iterating through those designs over and over and over again, to get it to where someone goes, Oh, that's simple. I could do that.
Tim Bornholdt 40:33
It takes a lot of work to get to that point too. I mean, even looking at something like Apple with the iPhone and with it, you hear all these stories about Steve Jobs where he infamously didn't want any cables coming out of the computer or, you know, the less ports the better. And it's like this constant back and forth with users because some users, yeah, you can have a wireless keyboard and a wireless mouse and they never plug any hard drives or anything into their computer. So no ports would be fantastic. But then there's other users like me, I'm looking at my computer and all four of my USB ports are plugged in right now. And I wish I had 10 more because I plug stuff in and out every day. So it really, you know, it's hard to bash on a company that is clearly making billions of dollars a day, but at your stage at a startup stage, you can sit back and try to really figure out what your core audience is going to need and use and continue to iterate until it is just so simple. Everyone wants just, I want to push a button and it does this thing. And there's a lot of like, you know, step one, push the button, step two, question mark, step three, the task is done. It's like that step two is up to you to figure out how many like point a-b-c-d-e-f-g it's going to take to make it so the users just doesn't have to do anything and it's done.
Amber Christian 41:55
Exactly, exactly. And that's what the research is for, is helping you understand that and helping you understand those scenarios and those use cases and the way that they're using it. And I do the same in my demos, we ask a lot of questions, even as we do demos as well, about what people are experiencing, so that we can, one, do a better job on the demo. But it also helps us understand for our roadmap for things we might need to build for the future as well. So that whole engaging with customers and showing them the product, and it's scary, and it's hard, right, to go ahead and do that kind of stuff. And I will say I had to grow a lot to get used to that. And even now sometimes when you'll get feedback in air quotes about certain things. Like, Okay, you just, you know, that's part of the job, right? That's part of what I have to do. Because my end goal was about helping people run more productive meetings, not me running more productive meetings for them, helping them run more productive meetings. And so it really had to be about what they were doing with the product in the end. And when you keep your focus on what they're trying to accomplish, and the problem you're trying to solve, that also takes some of the sting out of, Well that feature's ugly. Oh, I don't need that. Or that's not how I think. Okay, well tell me more of how you think. So that you can understand. Because you want to understand. Are they an anomaly? Or is it part of a larger pattern you just haven't seen yet?
Tim Bornholdt 43:28
And that's always a hard question too, like, how do you take, you know, you can have a feature that you sit in front of 10 people, and five of them absolutely love it, and five of them absolutely hate it. How do you figure out whose feedback is the feedback that you actually incorporate?
Amber Christian 43:44
Those you think that are most likely to buy is one way.
Tim Bornholdt 43:49
That's it. That's the best way. Yeah.
Amber Christian 43:51
That's one good way. That's why you asked the questions about why to people. Whenever you're showing features, ask why. You want to understand what it is about one design or approach that appealed more than others. We had, in fact, there are some things in our design that we've had people where we had nearly split decisions. We had that happen on a couple of things. At that point, I just had to make a judgment call, you know, as a founder and say, Well, I think we're going to do it this way. And we can revisit that at a later stage, you know, when we're further along for people that might want it to be done differently.
But that is a tough one, when things come out really close. I found that most features actually didn't come out that close when we would put competing designs up. And competing designs are actually kind of fun. And you should invest a little time and effort into this because you learn a lot out of that process when people vote on things about how they think. And that was also a really good way to elicit more use cases as well, is do you like design one or design two? And why? So they would vote and we would go forward from there. So it's a really fun process because you're getting into the inner workings of how people are thinking about your product and how they want to use it, and where they want to apply it. And I will tell you, though, that, you know, click-through prototypes are great in the surveys and the feedback and all that is absolutely wonderful. But you should be fully prepared to discover that you will probably miss some features too as part of that process that will show up very quickly when people are live testing something as well. I would say like an alpha testing round is also really good, and so like real live people, not you, not your team, but actually get some alpha testers. And so we did a closed alpha test. And we definitely discovered some features where people were like, Oh, that didn't come up in the review sessions or maybe came up once so that looked like an anomaly, that turned out to be something that lots of people wanted when they actually used it. Because we're all human, right? We think of what we can at the time, but it's really hard to know, even from a click-through thing, how would I really use this? Once we had people in there and said, actually try and use this, like, Oh, I need this, and I need this and I need this. I don't know what this thing is here.
Tim Bornholdt 46:22
We had, we did this big app release a few months back and it was an alpha release, like you said, and we had tested it to no end and we launched it and on the very first day, like three hours after we launched it, someone emailed us and they were like, Hey, I forgot my password. Can you set up a Forgot Password link? And in the entire six months that we had been testing out this software, nobody remembered that we needed to have the Forgot Password link in there. And you would think that a product that's literally three hours old that somebody would not have forgotten their password in that three hours. But somebody found it immediately. And those are the things where you're just like, I've been doing this for so long and you just want to like, take off your hat and throw it on the ground because you're just like, I can't believe I forgot that.
Amber Christian 47:16
Invariably it will happen the moment you release it, someone will do something like that. Our forgot password broke somewhere along the way and wasn't working right. So I don't know, maybe we have a Forgot Password theme.
Tim Bornholdt 47:31
Nobody comes to me as a software developer and says, Hey, I'd really like to build a Forgot Password feature. It's never, ever been a thing anyone's ever wanted. But it's always as soon as we launch, if we didn't have it in there, that would be like the number one thing that people ask for because, yeah, it's not sexy by any means. But it's like, you know, everyone seems to have problems with their forgot passwords. Just a thing, I guess.
Amber Christian 48:00
There's plenty of things that are unsexy about what we do. Let's face it.
Tim Bornholdt 48:05
You get under the hood a little bit, and yeah, you just back right off. I want to be mindful of your time. So I wanted to ask one or two more different topics real quick and get your thoughts around it. Now I read this, and you can correct me if I'm wrong, because I've learned to, you know, believe it or not, not everything on the internet you read is true. So I like to verify it whenever I can. But when you were building Bella Scena, did you have, like, typically when somebody goes to build an app, they go to like an agency or they hire some developers, or, you know, they kind of take one approach and stick with it and go. But it sounds like you took kind of a different approach where you had, you know, some internal employees and some external like an agency or something like that to outsource it. Can you talk about how you actually got Bella Scena built and from like a who built it and then how you got the different, you know, different components and different teams to focus on different features and parts of the software?
Amber Christian 49:14
Yes. So initially when I started out, I wanted to be careful of some things. And I wanted to make sure that a certain amount of knowledge was held in house. So thinking about, so if I step back and think about how did I decide what to outsource and what to do internally? There's probably about three different criteria I looked at. So first, I thought about the criticality of it, and how critical is it to what my business is doing? The second thing I thought about was the repeatability, like, is this a one time thing or is it something I'm going to need to do over and over? And then the third way I thought about was the ability to actually source it in your market for those skills.
And so what I did is I had an internal employee at that time that actually built the back end of the code for the product. And the front end was actually built by an agency. Because sourcing React skills was challenging in the market when we started it. It's getting easier now; it's a lot easier now to source it. But two years ago, when I started, it was not easy to source React skills. I mean, it was a very short list of people that had much experience with it at that time. Because if you step back and think about the language is not that old in the grand scheme, right? And so I struggled to source kind of the React that I wanted for the front end because I was looking to do some things like progressive web apps and other things in the future, getting a little bit nerdy and technical.
Tim Bornholdt 50:55
You're talking to the right person.
Amber Christian 50:56
I know. So I knew I needed to be able to source that. So that part I went the agency route. But also, my husband works in tech, too. And he does a lot of our security reviews and looks over a few things periodically here and there as well. Because he's also got a 20 year in tech background as well. So he kind of just keeps a little eye on things. It's not that he's in there all the time. But it's a sanity check, as well, periodically for me. So I had an interesting setup. I had an employee, and then I had my husband who's just nosy and you know, like, in most cases, Hmm what are you doing over there. But for the sake of our marriage, we did not ask him to build it. And I hired it instead because I had a bootstrap consulting business that was paying for it. Like I don't want to be my husband's boss. No, no, no interest there. But he had a lot of skills in security and other things where he could help us make sure some things were in order in the way that they should be. So I had that and I looked to the agency because it was really difficult to find those skill sets internally. And I wasn't ready to sign on to hire a person full time to do that. And so most of the contracting and even my employee worked part time for me over that build period of time.
So it was really about those, like I said, those three criteria like the criticality of it, the repeatability of it, and then the ability to source it from a skill set. And I use that more broadly too, not just in terms of who actually did my tech build, but a lot of things too. I had an agency do the branding for me, as well. And that wasn't something you're going to need to have done over and over and over again. You have that done one time. Legal you do that way as well, because you're not going to hire an attorney full time to work for your company, or even part time, probably, maybe for your company because you're doing trademark and contract and other types of work. So really kind of looking at several of those criteria. And that's how I did it at that time. Now that I'm way more comfortable, now actually the employee has moved on to other opportunities, and now it is all with an agency, although I do still have the overseer that looks at the security and some of the other things as well.
Tim Bornholdt 53:12
That's good.
Amber Christian 53:13
Yes, yes, absolutely. Yeah. The other part of it that I also like to talk about with their founders too is, one of the things you have to think about as you sort of lay out, you have to manage your risk as a founder as well, right? And you have to manage risk of, you may have turnover or something doesn't work out with an agency or you want to add new people. So something to really think about that I've done with almost all of my software subscriptions is really you should own those subscriptions. I know a lot of times people rely on agencies to have all of that. And I didn't. So Bit Bucket is mine. JIRA is mine, in terms of my subscriptions, and my setup, and a whole host of other things. You're like, well I don't want to have to spend any money for that. Yeah, but you have the continuity and the history that's there when it's all on your platform. So that was one thing that I did that I was forever thankful for. Even as we stood everything up, I made sure I was an administrator on everything as well, so that I would have access to things. Because you never know where things will pop up. It can be as simple as needing to add a new person. And oh, who has access to be able to do that? It's not even bad situations. Sometimes it's good situations or new people come in, or what happens if your developer gets in a car accident, can't get at your codebase. Now what are you going to do, right, and you had one person working on it. It's things like that. Part of your role as a founder is to think about your risks and be mitigating them to the extent that you can. Can't mitigate every risk. But I would offer that up as something to think about, that I've seen trap other people before, because they thought, Oh, well, I don't need to have that. I'm not going to need that. Like, oh yeah, you should have that a long time ago.
Tim Bornholdt 55:02
That's something that I still, you know, I always think it makes me a bad agency owner. But when I set up new clients, I always insist that they own all the accounts and that we have, like we get, you know, a sub account that is also an admin, but that we aren't the owner, because at some point, whether or not it's under good terms or not, there's either the product grows and you need to bring the project internally full time or maybe the project shuts down and or maybe we tick you off and you need to go somewhere else. But like all of our server stuff, all of our Bitbucket accounts, everything, we also set up separate accounts for the client. And same with like Slack teams, everything. We just want them to be in control of it for the exact reasons you're talking about. And that happens more often than not, like people come to us and they say, Hey, I want to, you know, get rid of the developers I'm working with, and you know, how do we start this process? And it's just like, if you're on still good terms with the developer, that's one thing. But if you're not, man, it is like pulling teeth to find where all of those different assets lay, and where you can, you know, actually get control of your own stuff, which you'd think you own all that stuff. But if the agency set it up under their name, good luck.
Amber Christian 56:22
Right, and that's something people don't talk about. And I've tried to start talking about it more, because I've talked to other founders and seen other people run into that situation, where they said, Oh, well, you know, they're claiming I'm gonna have to pay them a bunch of money in order to get my code base. And you're like, wow, I don't think I should have to pay that. Because it's, you know, an argument about whether quality or whatever it is, and you're like, that's the last thing you want to worry about as a founder, really, the last thing you should be thinking about as you're building your company. And so with a little bit of forethought, and again, that kind of idea of, well, should I have it or what's the risk to me if something goes wrong? Using that kind of as a decision maker, as opposed to saying, Well, I don't want to spend $20 a month for this subscription, then you're like, Oh, I wish I'd spent $20 a month.
Tim Bornholdt 57:09
Right. It's just like if your computer crashes and you lose all your photos from when your kid was a baby, it's like, how much would you have paid to have like a, you know, $5 a month to have your hard drive backed up? It's like, come on. You quickly regret that decision.
One last question before we go, again, I'm trying to be mindful of time. So, one last question. So I also read, again so you have to confirm this, if it's accurate, that Bella Scena was funded just by you, right? Was it bootstrapped?
Amber Christian 57:48
Yeah. It's bootstraped.
Tim Bornholdt 57:49
So how did you arrive at doing that decision? Because I see all this stuff on news especially around like the Twin Cities where you have to get VC funding. And you have to go out and raise a seed round. And it's imperative. So I like talking to founders that are bootstrapped like myself because it's a different route. And so talk a little bit about the decision to go that route.
Amber Christian 58:13
It was made for a series of practical purposes. And I'll be completely honest about what they were. At the time when I started this build, I was on some long term multi year SAP contracts. So I knew what kind of revenue I could expect from my existing consulting business. I did not quit the day job so to speak while I was building a startup, because you're just inviting Murphy into your spare bedroom. That personal philosophy. Other people that works great for. For me, I also wasn't ready honestly to say, I'm just gonna stop this thing and start this other thing. That was too much of a jolt for me, just personally.
So I had that existing consulting business and said, Okay, I've done well. I was at the top of my industry there. And so why, you know, I wasn't going to quit and get out of long term contracts. So I kept those contracts as well. And that provided the revenue to allow me to bootstrap. The secondary reason I did it is if we get really practical about numbers about what it looks like to be a female lead tech company that is trying to raise venture, that's a long road, if you're going to go that route. It's something like 2% to do it. And so it isn't really something I want to take on right now. The other thing I knew, because I've been in the startup world for a long time as well is, the nature of what gets funded and at what stage has changed over the last seven or eight years. Probably seven years ago, eight years ago, you could get funded off of a concept. It's really hard to get funded off of a concept. Today, it's harder to get funded off of that. A lot of people want to see an MVP and want to see some sort of traction in the market. And that's really hard to get to with a concept deck. I mean, yeah, you could pre sell and do some other things. But there were some real, just real practicalities that I said, Okay, what are the odds that I could go fundraise as a pre revenue startup, knowing I was building differently as well, right, in walking through this process? And I said, I don't like my odds. So I bootstrapped it at that point, because I could.
Now, what I'll also tell you is, I don't know if that'll be the final answer. I don't know if I'll fundraise or not at some point. It really depends on how it plays out. So I've said, you know, if I end up in a situation where I end up with some exponential growth, then maybe I'll need to in order to staff the way I might need to. It just depends on where the story goes. Essentially. And so the final chapters of this aren't written yet. I'm super interested in some of the alternate capital types of things that you've seen come up where they're a little bit different models than traditional VC. I just haven't decided yet. So I started out bootstrapped. And for now I'm bootstrap. But we'll see what happens in the long run.
Tim Bornholdt 1:01:09
Well, it kind of goes back to what you talked about with managing risk. I think that it's really smart. If you have the means and the capability to keep your day job and work on this project, on your side project or, you know, whicever perspective you're looking at it from. It just makes sense. And I think also, a lot of times people get stuck on, you know, they have an idea for software, and they just don't know where to go from there, and think you need to go and raise money or go and do this or that to get it built. And there's so many ways that you can, you know, like you said, build a clickable prototype or build different things to test the idea out and go out and do the hard work before you go and get it built. And once you kind of go down the path further, it's like, just do something. I think a lot of people just want to go out and like the good old days of like you said years ago where you could have an idea and go shoot 18 holes with your body and have a $100,000 check written. That doesn't really happen much anymore because people want to actually see progress and get things done that way. So yeah, not to like shut the door on ways to fund the business because yeah, sometimes VC money is the only way if you are seeing some huge hockey stick growth.
Amber Christian 1:02:30
Absolutely. And that's why I said this, the rest of the story is still to be written. But if I were to start over today, I'd look at no code solutions. If I were some folks that are looking to actually do some things, can you actually prove some things out with a no code solution before you go the route of having an entirely custom built software? Because there's gonna be overhead and things that come along with that. And that might be another avenue to look at because you're seeing a proliferation of providers for that and information about the whole no code movement as well. So there's ways to actually get through and actually build out your products without necessarily having to try to go raise a ton of money right away. And it's a tough process. Emotionally it's also a tough process and you have to be willing to commit yourself full time to that process. A fundraise is not something, you know, oh, yeah, I have a couple of calls and I have the money. No, you really want to do your homework before you think about doing a fundraise. And I've been doing mine too, as I think about, well, would I want to fundraise at some point or not, and say, Okay, well, what would it really take? You're probably talking four to six months full time of your life, just to do the fundraiser. And so you have to be prepared for that. So I want to make sure I walk into the decisions I'm making with as much information as I can get, so that I can make whatever is the objective decision at that point in time based on the situation I'm in.
Tim Bornholdt 1:03:52
That's fantastic advice. I think that's a fantastic place to leave it too. I really appreciate you taking the time to come on the show today. Amber, how can people find out more about you and Bella Scena and Wonderly and everything that you're up to these days?
Amber Christian 1:04:06
Absolutely. So you can find Wonderly, which is our parent company, at wonderlysoftware.com. And you can find Bella Scena at meetbellascena.com. And I'll tell you that Bella Scena actually means beautiful scene. It's Italian. So if anybody went, what does that actually mean? That's what that means. And you can also connect with me on LinkedIn as well. And I'm on Twitter, beingwonderly is my handle on Twitter as well.
Tim Bornholdt 1:04:30
Everybody go and check it out. And thank you again so much for coming on today, Amber. I think this was a really informative conversation.
Amber Christian 1:04:37
Thank you for having me.
Tim Bornholdt 1:04:40
Thanks to Amber Christian from Wonderly Software Solutions for joining me today on the podcast. You can find out more about Wonderly by visiting wonderlysoftwaresolutions.com.
Show notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing Hello@constant.variables.co I'm @TimBornholdt on Twitter. And the show is @CV_podcast. Today's episode was produced by Jenny Karkowski and edited by Jordan Daoust.
We'd really appreciate it if you took a couple of minutes and left a review on the Apple Podcast app. It shouldn't take you much time at all. And it really does help new people find our show, just head to constantvariables.co/review and we'll link you right there. This episode was brought to you by The Jed Mahonis Group. If you're looking for a technical team who can help make sense of mobile software development, give us a shout at jmg.mn