The SaaS Venture

Aaron and Darren dive into the design process for new features and product updates.  Whitespark and GatherUp take different approaches to this process and we look at each process to see what works best and why for each team. 

Helpful links from the episode:

FULL SHOW NOTES

[intro music]

00:12 Aaron Weiche: Episode Five, The Design Process.

00:16 Speaker 2: Welcome to the SaaS Venture Podcast. Sharing the adventure of leading and growing a bootstrap SaaS company. Hear the experiences, challenges, wins and losses shared in each episode, from Aaron Weiche of GatherUp and Darren Shaw of Whitespark. Let's go.

[music]

00:43 AW: Welcome to the SaaS Venture Podcast. I'm Aaron.

00:46 Darren Shaw: I'm Darren.

00:47 AW: And we are super excited to talk this week 'cause it's been a few weeks since we've connected, but we have a common theme. I just got back from a week in London, and you're headed over to England in a handful of days, so we like...

01:05 DS: Yep.

01:05 AW: We almost could have met and recorded a podcast live from London.

01:09 DS: We're gonna do that eventually. For sure we're gonna be at the same place. Maybe when we're at MozCon we should definitely plan a podcast when we're there together, that'd be awesome.

01:17 AW: Genius. And should we have a live crowd and a T-shirt cannon, and that kinda stuff?

01:22 DS: Yes, definitely. And an applause sign, so when we say something funny, someone flashes the applause button.

01:29 AW: There you go. It's you and I, and then hopefully three people and then our T-shirt cannons.

01:35 DS: Exactly. [chuckle] And some guys showed up to get free scones or something.

[laughter]

01:41 AW: Totally. Yeah. If we give enough good free stuff, they'll show up.

01:44 DS: Yeah, for sure. So, yeah, I'm going to London in a couple of weeks here. I gotta go to London to do a presentation at BrightonSEO, and I'm also doing a training session. It sounds like you've got some training stuff coming up, too. Tell me about your trip though. How was London, what was the best thing?

02:00 AW: Oh, the best thing, regardless of location, it was the first trip, my wife and I, where we've had seven days together since our first child, which she turns 15 next week.

02:11 DS: Wow.

02:12 AW: Yeah. Plenty of three, maybe even a four-day getaway, but having a full week... At some point midway, it was just like, "Wow, we've gotten so much time together." We maybe ran out of things to even talk about, and then we're like, "Okay, cool, silence is even cool," and then we just found other things to talk about. It was so great.

02:36 S2: Oh, that's nice.

02:36 AW: Yeah. We divided our trip halfway between the countryside of England, so we went out to an area called the Cotswolds, about an hour, hour-and-a-half outside of the London area, and super small little villages, one lane roads to get in between, driving out there was nuts. Man, there were so many times where I thought for sure that one side of the car was gonna be sheared off by the other car.

03:03 DS: Right. Do you ever have to stop and one car has to reverse until the road gets wide enough for someone to pass?

03:09 AW: Yeah, we totally had some of that going on. And just so many times where the locals they're still doing 40, 50 miles an hour on a one-lane road and I'm like over to the side, and then there's stone walls next to every road. There's no shoulder. It was just crazy. I definitely, out loud, shared how I felt a few different times, and I couldn't believe we never even touched mirrors out of all of it. It was crazy.

03:37 DS: It's funny, I had that same experience in Italy for sure. Driving down these tiny little roads between buildings, and I'm like, "How are we both gonna fit through there?" But then you manage to do it. And the locals are like, "What's wrong with you? Just drive your car, man."

03:52 AW: The locals stuck behind me hated me, because I was nowhere... When they would post the speed limit, I'm like, "How can somebody go that fast? I can't go 40 here, that's not happening."

04:05 DS: Totally. Yeah.

04:05 AW: Yeah, it was great. And then just the beauty and the calmness and the serenity of out there was awesome. I really, really loved that part. Then we went into London for four days, and that just such mixture of... We went to the theater, just so much sightseeing, so much history. It's like everywhere you turn is something that you would never see in the States. And that's the cool part about it to me, is just photographic visuals of little alleys and buildings, and little cafes and pubs, and things like that, where it's just like, "Oh, my... " You're in this huge area, but every 10 feet is something to look at.

04:45 DS: Yeah. I saw that on Facebook, your photos were beautiful.

04:48 AW: Yeah. Not even close to all the ones captured, those are just some of them. Yeah, it was really, really great. And, yeah, I'll give you a few tips. There's just so much to explore there, I would love to go back. It was my first time, and I'd be very excited to go back.

05:07 DS: Yeah. Jill and I are in a similar situation. We've never taken a long trip like that away from our daughter. She usually comes with us if we're going somewhere for a while. But just like two nights most... I think two nights is the most we've ever done actually, we've never done more than that. She's eight now, we've got another seven years, I guess, before we can have the seven-day vacation.

[laughter]

05:29 AW: Well, hopefully you get it in sooner than I did, 'cause... Oh, man, it was really great, it was awesome for both of us. You're headed over to London to do a conference, right?

05:42 DS: Yeah. I'm speaking at Brighton and also doing a training thing, so I've been very busy trying to... I'm doing a really interesting case study, where I take a business from nowhere, like the brand new, zero online presence business, and I've been trying to see how wide I can get them to rank in the local results, so tracking their location across multiple zip codes, and doing everything I can, like all the regular local search stuff, and being able to measure the impact at every step, which has been really great. So, it's like, "Okay, they got three new reviews. Wow, look at what happened to the rankings." Just those three reviews gave them a massive ranking boost. And so, because it's so dialed in and they had nothing going on before, it's this clean, clear case study of what happens at each phase and how that impacts local search. It's been really great, I'm excited about that. But it's been taking me too long and I've been putting too much time into it and not enough time into preparing for the local search training I'm doing on one of the days, so I have to spend about seven hours giving a full day training course, so I'm gonna be really slammed all next week trying to get all that stuff done.

06:47 AW: Yeah, so much work all the time to get ready for that stuff. Your study sounds awesome. I'm gonna be excited. Hopefully, you'll share that deck with me when you're done with it.

07:00 DS: Yeah. Basically, I've got four months into it for Brighton, and so I'll have that much data, but I'm also going to show it at MozCon, so I'll have another two, three months of data to present and more things, as we get more links and as we do more things, how that impacts local search. Ideally we'll have them ranking round the whole country and local search by the end of it.

07:25 AW: Nice. I like that. I'll be able to see it in person then at MozCon. And speaking of MozCon, I'm excited, GatherUp is gonna be one of the sponsors for MozCon.

07:36 DS: That's awesome, yeah. We've done it a few years and it's been really great. You've done it before though. You were just the local?

07:43 AW: Yeah, just only the local SEO event, haven't sponsored the regular one. But it's such a fit for our audience, 'cause our two biggest audiences are multi-location and brands, and then agencies. And that's the entire thousand plus people is, for the most part, either an agency person or someone in-house at a larger brand.

08:05 DS: I think it's gonna be huge for you guys, it's gonna be really, really good. You're gonna have a ton of great conversations and, yeah, it's definitely your audience. I thought Moz had some kind of review product in Moz local. No?

08:18 AW: They have a review monitoring for a couple of sites, and that's really about it. Comes from your GMB integration, stuff like that, but nothing for acquisition or review widgets or all of the other wonderful things we do.

08:33 DS: Cool, cool. I'll try to see if I can squeeze a mention of GatherUp into my slide deck for you.

08:39 AW: There you go. Every time you do it, it buys you one beer.

08:42 DS: One beer? Wow. [laughter] It's great. I'm gonna get a six-pack eventually.

08:47 AW: Yeah. I gotta keep my budget low after spending on conferences.

[chuckle]

08:53 DS: Totally. Having a booth at MozCon is about a billion times better than a booth at any other conference, because they only let eight businesses in, and they're right... It's like, everyone that's coming into the main conference center to watch the talks, they walk right through the booths every time. And then after the conference gets out and they open the doors for a snack time, the snacks are right there where you're hanging out. And so it's like everyone comes right to you. It's not like you have this expo hall, which is often separate from the conference, so you get massive exposure. It's the best place I've ever seen for a conference booth. I think it's gonna be great for you.

09:35 AW: That's exactly what I shared with our team, because none of... I don't think anyone else from our team has ever been to just the regular MozCon. I told them that, the placement and the numbers. You're not one of 100 or 500 booths. You're not tucked in a corner, you're not hoping people find their way to you. You're right in the flow and there's just a handful, and you're so visible and so accessible. I'm really hoping it's gonna be a great thing for us, I'm definitely excited about it.

10:06 DS: It's gonna be good. How much time do we have here? I did wanna ask you, what is your conference process? But we're into 10 minutes, let's get into the meat of this podcast.

10:15 AW: There you go. Another time, we'll go into it. Maybe after MozCon, then we can talk about how I did IFA a couple of weeks ago and I've had a couple of really good leads. I'm hopefully closing a deal or two from that coming up, which totally takes care of what that investment was, and then we'll see how Moscone goes and then, yeah, let's do that for a subject down the line. We might even be... We'll be in double digits by then. It'll be...

10:40 DS: What do you mean?

10:41 AW: Episode 10 or 12. Right?

[chuckle]

10:43 DS: Oh, yeah. Totally. Exactly. We could actually talk about that at MozCon. That might be a good topic for when we're at MozCon.

10:50 AW: Boom. Talk about conferences, right?

10:51 DS: Yeah, totally.

10:53 AW: All right. With that, just as you alluded to, and this week you brought up the main topic of looking at the design process. You have a number of things from when we started chatting before we hit record and notes put together, but, yeah, I'd love to see you break this apart and talk about some of your challenges and share some of the things that we're doing and see where we end up with all this design stuff, because it sure does matter.

11:26 DS: It does matter. This has come up for us recently because we just finished our revisions on the brand new local citation finer that we're building. We tore it down, started from scratch, rebuilt the whole thing, and as a result, we have a whole new interface. The way that our process works is... The first phase of this local citation was what we called feature parity. We're building in a brand new development stack and bringing it up to modern standards, and as we're doing that, we're re-envisioning some of the UI, some of the layout, some of the design, and just improving things as we go. We got it as far as we could, so now we have a feature parity version of a local citation finder. It looks a million times better, it has a lot of new functionality, we took it quite a bit beyond feature parity. And it looks great.

12:25 DS: It looks a lot better than the existing one, but I don't wanna stop there. And so what we've done now is, I've given it to our designer at this freelance company we use out of Croatia, Creativa Studios. These guys are awesome. And so they're gonna take a pass through it where they just go through each screen and Photoshop it up, so they put their spin on it. And then they'll come back to us and we put a fresh face on it, and then we launch the thing. And so that's been our process for this software, and it really got me thinking about design because I feel like that's pretty ass backwards.

12:56 DS: I think a lot of businesses, SaaS businesses, go the other direction. They start with the designs, they start with the wireframes, and they conceptualize everything. And they do a lot of painstaking planning, then based off of the plans and the wireframes, the designs, they start building the software. And I can see the merit to that, but I have to tell you, every time we've tried to do it that way, what ends up happening is, by the end of it, we have a completely different product than the designs. And it works, but a lot of that initial time spent upfront is wasted because, once you start building the software and using it and trying it and tweaking it, you realize a lot of those original concepts don't work or you want it to be slightly different. And so that's why I feel like our organic approach... It works for us anyway. So, we just build first and design after. We put a better face on it after. 'Cause it's the functionality and the user interface, and my developers are decent enough at design to make it look fine. And then we can make it look really good after the fact.

13:58 DS: What do you guys do over at GatherUp? How do you build a new feature, for example? Do you completely design it first, and then build it out, or do you kinda build it and then say, "How do we make it look better?"

14:10 AW: There's definitely been an area of evolution for us in the last three-and-a-half, nearly four years since I came on, just 'cause I'm a much more process-driven person, plus, as the company has grown and things like that, where we start now is any new feature basically starts in a feature spec just in a Google Doc.

14:39 DS: Yeah, that's how we do it, too.

14:39 AW: So, you're writing down, "Here's the business case, here's why we wanna do it," and then you just start writing down the little things, the dependencies, "In this situation, it was, do this, here's what to keep in mind." And we try to get that through a first pass as far as possible. After that, what it used to be, and I don't know if I should talk about where we came from or where we've arrived at first, but where we came from is... Once upon a time, we would freelance it out. We wouldn't even really create a design spec, we'd create a wireframe. We'd be conversationally all be talking about it, and we'd either create something where we could all mark it up or create examples off of existing screens, or whatever that might look like, and then we would take it to a designer and ask them to design it. Or we would even say, "All right, let's just re-use some of the elements we have from this screen and that screen," and we'd have our devs build it without a designer. And let's just say all of those failed miserably in many different ways.

15:46 DS: So, what's your process now?

15:48 AW: Now, it goes to a feature spec. One big change that we did is, we said, "All right, we're gonna hire a designer." 'Cause, for us, it was hitting upon a couple of different things. One, we badly needed a V2 of our interface. Our interface felt dated, there is some not-so-great decisions. Our style sheets were starting to blow apart because there was just no consistency. We had a number of things. And so I just looked and I was just like, "All right, I'm a very visual person, and visual interface and all that really matters to me." I basically went and tapped someone who was my creative director at my previous agencies and recruited him, and just said, "Here is an opportunity for you. Everything needs to be redone, we have a re-brand coming up as well." And we basically brought him on as our chief experience officer. He's the one responsible for how people touch the product and interact with it, all of these different kinds of aspects to it.

16:47 AW: So, we go from feature spec to now he's usually creating what we would call a low-fidelity wireframe, and we're using that and InVision to make it clickable, so you can click and move around and start to get, like, "All right, here's how we move through three or four things," to get rid of just static design, where it's like, "Yeah, it looks great." And then, just as you're alluding to, once you click or do something, it starts to fall apart. So, we drive home that idea in InVision first. Once he gets to that, then he's like, "All right, we've solved most of those things, we understand it," and then we bring it into design.

17:22 AW: The other thing we have going for us is we've also created a library now of this is what this is and how it's used. So, getting a lot more down with what the size things are, how tables are presented, buttons, spacing, whatever that might be. It's not very Wild West at all, 99% of anything we do, that element has already been created somewhere. He takes it through design, and once we hit a point for the back and forth and that's good, then we take it to our front-end devs. Front-end devs build it and stand it up, and we're able to... They're gonna wire in as much as they can, just without data into the back end of the product. And once we approve that, then it's ready to... Basically that's when we insert it into a sprint with our engineering team. Engineering team then takes it through our feature of internal testing, beta, public beta, and then release.

18:17 DS: Does it feel like there's any waste in that process? In terms of... I don't know, for me, it sounds like it takes a long time to go from that Word Document, where you describe the feature, to actually having this in production, 'cause you've got many different steps you have to follow.

18:37 AW: Yeah. You can look at it that way. For me, I view it as this all serves as different points for people to touch it, feel it, interact with it, socialize it, get people used to it. It's amazing all the things that happen, and just as you alluded to, there is nothing like when you actually really use it. We probably learn the most about our product when we do our stage of what's called a private beta, when we flag it in our product, you could turn it on, and we can start using it at test production accounts we have. That's where we really learn the most. But the good thing is, by having the same person doing it, who's using the product, going through all these design processes, he sees some of those things before it happens. And even us as a team, we bring up a lot more things. Our customer success team is fabulous at... They right away look at it and they think of something that they get asked all the time, and they're like, "All right, well, what about this? 'Cause this is what's gonna be asked about there."

19:39 DS: Right, yeah.

19:39 AW: We do get those iterations within there, and there is stuff that you could look at, like, "Wow, that seems excessive." But for us, it's really helped tied off a lot of details 'cause for a long time, we were pretty much like build, build as fast as you can, and throw it out there. And then you'd be like, "Oh, here's all the stuff that we need to go back and fix," or, "It could be better," or, "We didn't even think about that," and things like that. So, we feel like we've arrived at a place that allows us to hit the quality that we want.

20:06 DS: Yeah. Our approach is, we build it first and then we tweak it. I'll look at it and I'm like, "Okay, we wanna change this, change that." And then the dev team could turn around those changes in... Sometimes while I'm on the call with them, they're like, "Okay, they'll change it in the code," deploy, I'd be like, "Okay, refresh." So, I'm on the call, we're changing, we're updating it regularly. And then once I feel satisfied with it, I throw it over to Jessie and Nick, have them take a look, throw it over to Brianna or our customer service team, have her take a look at it. And then we get it pretty much, like, "Yeah, the functionality of this is great." Then we just put some lipstick on it. We get a designer to make it just feel and look a little bit more polished, and then I feel like it goes out the door. And to me, it feels like some pretty rapid development, it's a great way of getting to a launch-ready product pretty quickly. It works pretty well for us.

21:05 AW: Yeah. And I think that's an important part. At the end of the day, lots of ways to achieve something. It does come down to whatever works best for you in getting those things out and once... I feel like we're pretty agile. We talked about, in an earlier episode, where we've gone to a feature a month that is gonna get delivered, and then we have multiple others that fall underneath it. We kick out a lot of updates, and we push a lot of really, really, in our world, what are big features, and a lot to tackle on a consistent basis. And to me, there's even more we can explore. Our chief experience officer has been with us for a year now, but I still think he's halfway there to where we really need him and want him to be, because he just needs to continue to use the product more and understand it more.

21:57 AW: And really it's unlocking things. There's always a straight line way to do something, and that's the one thing I worry about with your process, is you come into it with this bias of, "Well, here's how you do it." But you didn't take any time to explore, what are the other ways to do it, or how would this work in other environments, are there steps I can cut out, or what's intuitive for the user, things like that, that what we've found in our process in doing it and creating some of these motions in just like a clickable wireframe, is you get people using it and talking about it really early that sometimes, "Oh, well, we can reduce clicks and do it this way, or if we add clicks, it takes all this other stuff off the table and makes it easier." I think there's some really interesting dialogue when you do that, so I really look at it as, as fast as we can get it to something that can be socialized. And you're, in essence, doing it that same way, too, you're just doing it in a full build, to some extent.

22:55 DS: Yeah, one of the failures of our process... Well, I'm gonna even call it my process. My developers might say that the way I do it sucks. It's frustrating for them, because one of the things that happens is I get this idea, I want this feature, and so I scope it out, and then they start building it. And then we have to ditch it because we realize, "You know what, that's not gonna work the way we originally planned." And so they've already spent the time to program it, but we ditch it, and we come up with a new angle. Whereas with your approach, you avoid that, because you think about it in the design and wireframing phase before all the time has been put into actually programming. I can see the benefit there, for sure.

23:39 AW: Yeah. In any process, fail early and fast, if you're gonna fail with those things, so that you can re-calibrate or restart from what you learned or where you went wrong, and then try to go from there as fast as possible.

23:55 DS: Yeah. There's gotta be some good guides out there, blog posts on processes for software development, that I just don't feel like I spend enough time reading and investing in. Looking at all those different things and thinking about what do we wanna incorporate in our process and how do we wanna do our next project or feature release. Right?

24:13 AW: Yep. And sometimes you play around with it. We're definitely constantly adding things or just tweaking some little things. We have our main steps and framework down, but inside of that, we're trying a lot more things. We realize in a lot of things, "Okay, we need to socialize this, or we need to have more conversations or even a presentation of it with our engineering team," because we give it to them all wrapped up, but they might not always understand the business case or the use case or some of the things like that. And for a while, we'd do a great job of creating the feature spec, but then all the changes that we would make while we were designing and building, we would never update the feature spec. So, it was like, it got it started, but we really realized, "Oh, well, this thing, it should be the narrative of the feature. And as we make these new options or choices, we need to go back and update that." So, the final thing you do, that still serves even when you're at step 28 to finish it up, that feature spec is still informing you or something you can cross-check against to make sure you did it right.

25:22 DS: That makes sense, yeah.

25:23 AW: Especially when you pass it off to so many hands, because ours is going through half a dozen hands in the process.

25:31 DS: Yep. Our process is currently... It works, but I think one of the big ones that really stands out in my mind is the rebuild of our rank tracker. That took us two, three years, and it's because we kept going back to the drawing board on it. We'd build something and then we'd be like, "Yeah, that doesn't work." And then we would build something else and then we'd build something else, whereas I think a lot of that anguish could have been saved if we had more of a formal design process. And sometimes it works great. 

If we think about our new tool that we just launched, that review checker, that was mostly just one guy, Dimitri, thinking about it, putting it together, getting feedback, we tweak the system based on the feedback and eventually we've got something out the door. And it worked pretty well there. And I think a formal process for that small tool would have really slowed everything down.

26:27 DS: So, we were able to get something out the door quickly with a part-time developer by just letting him roll with it. And then he would show us what he's got and we'd be like, "Okay, well let's make this look a little bit better. Let's change the icons here, let's change the colors, let's move this and put it somewhere else." But the functionality never really changed. All that changed was the placement and layout and design, and that kind of stuff.

26:51 AW: Yeah. For the rank tracker, most of the things you kept coming back to, were they visual displays? Was it how you were displaying things more so than functionality?

27:01 DS: I think it was a combination of both. It wasn't really the design that was the problem, it was the overall architectural planning, I think, was the problem. And it's just a really big project, and there's two main components to it. There's the crawling architecture, that's a big complicated system that runs on the back end that does all the crawling, and then we have the front end interface that pulls in all the data. I think it was actually... Most of the problem wasn't visual, it was architectural. And so we went back to the drawing board a couple of times on that, based off of... Even technologies that we were using were problematic. So, we started with our database structure being in this one thing called Couchbase, and it worked great until we reached a certain capacity, and then it all started falling apart.

27:48 DS: Having to shift gears and rebuild something else, and then once you rebuild that, you've got to change something else, with the way that we're doing other things, that was part of the big problem. The system works quite beautifully now. One of our developers, Troy, has done a really good job with the crawling platform and the servers that we use for it, and the whole architecture of that is running really well now. So, glad to have that behind us, which allows us to rapidly develop all these other things right now.

28:19 AW: Yeah. Just because at the time now, I know a majority of your products are siloed from each other, do you have a consistent design theme and library across all of those? Is that constantly evolving? Do you introduce... When you introduced the review tool, did you introduce a new library for that? What does that look like for you guys?

28:39 DS: Yeah. No, we don't, which is bad. This is part of our problem. We do have this concept that we're building, it's called the platform. And we're building our new account system, which does all of our processing, and where customers can log in and see what subscriptions they have, their billing information. That's the base of it, and that's going to evolve into what will be an integrated platform. And so that was designed in advance. We have all the Photoshop files, all the InVision stuff for that platform concept. We wire-framed it all out. And now this software... I told you we just rebuilt the local citation finder. The design of that is being built by the same guys that designed the platform, using the same concepts. And so it will have a uniform design to our new platform. And then the rank tracker, I'm gonna ask the designers to take a pass through that as well to make it also uniform. And then the Holy Grail will happen some point in 2019, where everything is integrated into one platform.

29:40 AW: Yeah. That'll be big, but I think you'll find, just as we did when we started through the redesign of our application interface, that just working from a set library, developing consistency and predictable elements, that is such... I think that's such an important pillar in good design. Your team is not guessing, but also the user isn't seeing all those inconsistencies. Right?

30:07 DS: Absolutely. It's gonna be great. They know that our buttons are always on this spot and they always look like this. It's like that is what a select dropdown looks like in this application.

30:17 AW: Yeah. Those visual cues, that visual way finding just makes it so much easier. And we still have things... I think we still have four to five different pop-up designs in our product where it's trying to find, "All right, when can we sweep through and get those all on one?" That kind of stuff.

30:37 DS: That one little modal that's still that old design.

30:40 AW: Yeah. That kind of stuff just drives me nuts right now. I just had that happen today where I hit something and got into something where it literally, I feel like it was one of the first things ever designed in our product and it's still in there somehow. It's like, "Oh, remind me to never click on that in a demo again." It's terrible. [laughter] It's easier for me to avoid it than to figure out how are we gonna get that one thing changed to base on other pieces that are there?

31:11 DS: Yeah. I have a tendency to just derail my development team when that stuff comes up. As anything that bugs me, I'm just like, I'll just ping them on Slack and be like, "Would you be able to fix this this afternoon?" They're just like, "Drop what you're doing, just take a break. I'm sure you're getting tired of it, just fix this." 'Cause anything that bugs me too much, I just wanna get it done immediately.

31:31 AW: See, I have that power in our feature build process, beta process, whatever else, but our product managers now have got to the point where they're like, "Yeah, we'll get that in the next sprint, but... "

31:45 DS: Yeah. That's what we need at Whitespark, but right now I'm just like the ultimate dictator. It would be good to have somebody to be like, "No, not doing that. You can't derail our team 'cause we're working towards a sprint and we need to get it finished."

32:01 AW: Yeah. I both love and hate it. It's like, "No, I want this done ASAP." But on the other side, I'm like, "Man, I love that we have enough process and communication and things that don't get someone upset at me just because here's Aaron banging his fist that he wants this done." It's a good thing even though in the moment sometimes I wanna throw a tantrum about it.

32:23 DS: Yep, for sure.

32:25 AW: So, what do you think, based on this, do you feel like there's something that you know you wanna try different, or where are you at?

32:33 DS: If I think about what's on our software development roadmap, it's tough to say because... Actually, a little bit, yes, and so I think what we'll do... 'Cause we're finishing phase one of this local citation finder rebuild, which was done development first. I think phase two, we're gonna have a nice fresh design, we're gonna have all the functionality that we need for future parity, so a brand new system. Before we start development of the new features that I want, we'll actually wire frame them and then turn the wireframes into proper full designs, 'cause we'll have all of the materials to be able to do that. 

And so I think we're gonna get to that point that you're at now, where you can go through those phases for a feature, 'cause everything that we're building now, they're just new features on the existing well designed system. So, we're going to definitely approach it as from a design first perspective for phase two of that local citation finder. And I think that will work better, because then we can have all those discussions in advance before anyone starts writing code, and I think that's where the time savings will be.

33:38 AW: Well, and it's figuring out what's most important to you. There's pillars inside this of... For me, it was quality and consistency were the two biggest pillars. You're pointing another one out in being efficiency. I think when anybody looks to design their plan around design, however you're gonna map that out, is you have to figure out... I would start with, what are our pillars, what is most important to us. Obviously another one is user experience and usability to it. So, what are the three, four or five things you're gonna answer to? And as you build a process or figure out, who do we need internally on the team as compared to externally, or the talent pool or skill set, how do you answer to those and does it meet those core pillars that you know you need it to meet when you design it? And that's where I think that can be different for everyone else, based on how they view things or what's important to them.

34:37 DS: Right. Do you guys ever run your designs across your customers, you run it by the customers and say, "Hey, this is this new feature, does this look like what you have in mind?"

34:48 AW: Yeah, we definitely socialize... Especially with bigger things, we'll take it to people and see how they feel about it. Even in the case with you guys, when we do stuff for agency resellers, we're gonna say, "All right, how does Whitespark feel about it? And let's socialize this, part of the pieces, or let's explain it and see if they get it." And then if they do get it, then there's a lot of questions, like, "Oh, well, can it also do this? Can it do this?" That can be helpful as well. We've even gotten into that with our monthly webinars. Our monthly webinar almost always consists of, "Hey, here's the latest thing that we just rolled out, we wanna make sure you fully understand it. Here's what's right around the corner, possibly going into beta, if you wanna join, here's how to," and get them excited about that.

35:34 AW: And then the last is we almost always try to have something that is a sneak peek. So, we did that today with a... I just did our March webinar today, and we gave a sneak peek to a report that you can start to get people excited, and you give them something to look forward to, you get them something to get used to, that when you roll it out into the product, they're ready and waiting to utilize 'cause you've already talked about it and explained it, and they have the visual cue on it. And they're wanting it and looking for it, instead of it just being a surprise, which surprises can be good, too, but I find when we can seed it as we go along, it works out much better.

36:11 DS: I really wanna get into that. I feel like one of the things that we fail at at Whitespark is, we'll launch a brand new feature and we don't even tell anybody. It's like, yeah, we've got this awesome new feature and we didn't promote it, we did not do a webinar on it, we did not even tweet about it. Just like, yeah, it's this nice little new feature, whereas it's an opportunity to promote the value of this new feature and we often don't do that. 

We're just so focused on continuously building and adding new features and improving the software that we don't do a great job of promoting it. And I think what you just described, or that process where you get people involved at the early stages, you get their feedback, you socialize them, and you even get them into the beta already, all that stuff is so valuable and it's definitely something I'd like to incorporate at Whitespark.

37:03 AW: Now, it gets the hype going, it gets them excited about it. For some people, it's a feature or something they've been asking for, so it makes them feel like they're being heard and listened to. And, yeah, there's definitely a lot of wins on it that go a long way. And we're trying to find more and more ways how do we do that? Like our last feature, text back, we used a little explainer video just about the feature itself, and put that out there. So, it's like how different mediums can we use, so we're really trying to expand, even... I think we do quite a bit, but we wanna take it even further. 'Cause at the end of the day it is about marketing and storytelling and communication and getting those things across, and we wanna do as much as we can in them.

37:47 DS: Do you have a specific person at GatherUp that's responsible for prepping the webinars and marketing and writing up the emails, or do you do all that yourself?

37:58 AW: Yeah. I do way too much of it myself. One step we did take, we hired what we just call a product and content marketer last fall. And she's been great, she's taken a lot off my plate, from writing user guides and beta instructions and blog posts, and things like that. She still hasn't taken it all off, I still do all the emails, I still do all the webinars, and I don't know if that will ever... I wouldn't see the webinars being in there, but it's reduced 50% of my content output. Where I was, other than Mike Blumenthal helping out on our blog a lot, it was all me, and it was way too much. That has been a really big help, especially with all kinds of littler things, and I think we still have a long way to go. 

She's only six months in, still learning product, still learning all these things, and it's getting better and we're figuring out some of our processes and ways to excel there. But in my opinion, too much of it still relies on me to execute. I can be a great... If you wanna ask me about stuff, if you want me to spout off about it or anything else, I would love to be the motivation or the soapbox source, but to have someone else write and execute on it, that would be a dream come true for me.

39:17 DS: Yeah. I feel pretty lucky to have Jessie. Jessie's been with the company for nine years, she knows everything, she's also an awesome SEO, she knows the local search space really well. She does all of our newsletter, when we launch new features, she writes them up, she promotes them, she manages our social media. We're really lucky to have her to be able to handle all that. She can talk about all of our products, all of our services, and she can talk about local search as well as anybody. She's really great to have in that role, it takes a lot off of me. I don't have to worry about any of that stuff.

39:51 AW: Yeah. I like your Jessie. And if we weren't such good friends, I would steal your Jessie.

39:57 DS: Yeah.

[laughter]

40:00 AW: Everybody needs a Jessie.

40:01 DS: Yeah, she's pretty great. And when we go to conferences, too, she's the one that's there and she'll organize all the stuff and she'll talk to the customers. Yeah, she's great that way.

40:10 AW: Nice.

40:10 DS: Yeah.

40:11 AW: All right. Well, I think that puts a wrap on this episode. And in talking design, my advice to people today, and maybe, Darren, you have a couple of things you wanna share, but mine is define what your core pillars are that you want to anchor to and build a processor on that. I'm of the ilk that design individuals are so important, do not undersell what that takes, and if that means... In our case, where we hired someone with great expertise and allowed them to own it, that was a big change for us and it allowed us to work that process even better, so I think the design process is definitely an important one and not something to just cobble together, for sure, for someone building or enhancing a product in today's SaaS market.

41:00 DS: Yeah, I'd agree with all that advice. I would say that it is possible to build things with a more agile design second approach, and I think that our review tracker was a good example. If you have a developer that can design stuff well, then you don't necessarily need to put all of that effort in upfront, depending on what you're building, if it's a small little thing. If it's a big complicated thing, I do think there's a lot of value in putting more effort into the planning and design in advance, and I've learnt lessons there. And so take Aaron's advice on that one, and that's advice that we're gonna start taking a little bit more here, too, where we do the planning in advance, 'cause I think that there's generally good value in that and you avoid pitfalls in the future.

41:43 AW: Yeah. Well said.

41:45 DS: All right.

41:45 AW: Well, Darren, when we talk next, we'll be able to get your download of some time in England, in London, and good luck at the Brighton conference. Knock 'em dead, and find some time to enjoy yourself, and have a few pints, and eat some good food as well.

42:02 DS: Thank you. I'm gonna try to do all those things, it's gonna be good.

42:06 AW: You will excel, I have no doubt.

42:08 DS: The pint drinking anyways.

[chuckle]

42:09 AW: Totally. All right. Thanks, everybody, for joining us on another episode of the SaaS Venture. Happy to have you with us, and we will see you next time.

42:20 DS: See you next time.

[music]