The Shane Zilinskas Hypothesis: User Research and Empathy Drive Products From 0 to 1
In this episode of the Product Science Podcast, we cover how Dan got started in tech, why he built an agency of his own, and how they practice product discovery.
Shane Zilinskas has worked on many product launches for companies ranging from startups to Fortune 500. He started off as an engineer before finding his way to product management, when a book and a one-way ticket to Europe led him, together with his wife Kara McGehee, to build ClearSummit, an agency that has helped 100s of companies take their products from 0 to 1.
In this episode of the Product Science Podcast, we cover how Dan got started in tech, why he built an agency of his own, and how they practice product discovery.
Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, YouTube and more. Love what you hear? Leave us a review, it means a lot.
Resource Links
Questions we explore in this episode
How did Shane start a software product development agency?
- He and his wife both read the 4-hour work week and were inspired to apply what they learned.
- They were backpacking in Europe and he began getting requests to build and test prototypes and products.
- They built an agency that works with bootstrapped to series C startups.
How does Shane's team get started with a new product initiative?
- They conduct interviews on zoom to see how people use the product today.
- They also sit down with the stakeholders to understand their perspectives.
- As they design and build, they test prototypes with the users.
What advice would Shane give to someone thinking about starting their own agency?
- Be hungry enough to learn about things that come at you from left field.
- Find mentors. A 5 minutes conversation can change your perspective.
The Product Science Podcast Season 5 is brought to you by Productboard
Check out their eBook: 10 Dysfunctions of Product Management
If your product team is struggling, it could be one of the 10 dysfunctions of product management. Learn more about each dysfunction and how a product management system can help you address and avoid them.
Quotes from this episode
If you're running your own business, there's going to be a number of things that come out at you from left field and understand, and you won't know even how to deal with that challenge. And so, being hungry enough to learn what that challenge is, how to tackle it, and in addition to that, finding very strong mentors that you can talk to and that you value their opinion on because they've also been there before.
A lot of it is understanding who that persona is, what their actual workflow looks like, and what their workday looks like, and making sure that we're building a product that fits inside of that. Because if we can't fit inside of their workflow, then they're probably going to not use the platform and adopt it as quickly as we would like.
I feel like humans, a lot of times, have to hear things three times before they see the same thing. So, yeah. It's really important because we all come to it with our different perspectives and lenses, and we're trying to understand. We have multiple stakeholders and personas, and we're trying to empathize and be in their shoes about how they're seeing that. But a lot of times, we still put our own filter on it.
Transcription
Holly Hester-Reilly:
Hi, and welcome to the Product Science Podcast, where we're helping startup founders and product leaders build high-growth products, teams, and companies through real conversations with people who have tried it and aren't afraid to share lessons learned from their failures along the way. I'm your host, Holly Hester-Reilly, founder and CEO of H2R Product Science.This week on the Product Science Podcast, I'm excited to share a conversation with Shane Zilinskas, CEO at ClearSummit. Shane is a software engineer turned product manager who built an agency that has helped hundreds of clients go from zero to one. Welcome, Shane.
Shane Zilinskas:
Thanks, Holly. Great to meet you. Thanks for having me on.
Holly Hester-Reilly:
Great to meet you too, and happy to talk to you today. So I would love to start by hearing a little bit more about your journey. You mentioned that you started as a software engineer. How did you decide to pursue software engineering?
Shane Zilinskas:
Yeah, that journey started pretty early, actually, when I was probably 10 or 12. My dad bought me a Lego Mindstorms kit, and I was building little robots to run around the house and follow light or run away from light, and build little things like that. So I enjoyed coding from that. And then I sought out coding courses in school, and my high school offered AP level coding courses and I enjoyed that. Built some basic HTML websites and things like that. And then went to college at the University of Virginia for computer engineering, so a little bit of hardware also computer science. And then from there, I went and worked with the government doing FAA systems, flight control systems, and then started going more into the consulting and agency world.
Holly Hester-Reilly:
What was it like for you working for the government?
Shane Zilinskas:
Honestly, it wasn't my favorite. I like to move fast and try not to break things, and the government was very slow. Obviously, when you're building mission-critical systems, there is a reason to go slower and to make sure that everything is exactly how it should be, but it was more so than that. Things were extrapolated out to take away longer time to frame than they could, even if you had a proof of concept or total version done, they would still take a pretty long time to deliver. So it was a very slow moving process, and I didn't really feel like I was able to iterate on things or build out features in a way that was delivering a lot of value.
Holly Hester-Reilly:
I also worked for the government very early in my career, and it was too slow.
Shane Zilinskas:
Yeah.
Holly Hester-Reilly:
It's too slow, couldn't keep entertained.
Shane Zilinskas:
Yep.
Holly Hester-Reilly:
So I understand that for sure. So, how did you move on from there? What was your next step after that?
Shane Zilinskas:
Yeah, so really quickly, in that job, I realized what it was and that wasn't really where I wanted to be. Through my college career, I had learned a lot of C programming and low level programming, things like that. And during that time, I started learning more about product design, building web applications, and things along that path. So I took a few months and pivoted, and then began consulting building web applications for clients.
Holly Hester-Reilly:
Got it. So how did you make that pivot?
Shane Zilinskas:
Yeah, I realized I wanted to make that pivot really quickly, but it was also my first job and I was like, "I got to stay here for a little while." So-
Holly Hester-Reilly:
Yeah.
Shane Zilinskas:
... it's just like quitting on the first day. Yeah, I reached out to some recruiters and talked to some different recruiters, and they found me a role with a company that needed to re-architect their entire backend system, and they were looking for a consultant to do that. That company, now, it's a Berkshire Hathaway subsidiary. It's a media conglomerate, but it was mainly just talking to recruiters until I found the right fit.
Holly Hester-Reilly:
Got it. Okay. And so tell me more about that role with the Berkshire Hathaway company.
Shane Zilinskas:
Oh, yeah. This was much more in software engineering than it was product, but they had built a Python web application, and they had been adding onto it for about 10 years, and they had made a lot of bad architectural design decisions.
Holly Hester-Reilly:
You don't say. Is that a thing that happens?
Shane Zilinskas:
Yeah, and it just kept compounding. It was actually fun in a lot of ways because I think I removed about half the code base, because it was all duplicated code. And so I just created abstractions and made everything a lot more efficient. So that was about a six or a nine-month project with them. They were on a version that was eight years old. We were able to modernize it, bring them up to speed, create all modern architecture. So it was pretty fun, especially because when you can go through and add that much value that quickly, it's really enjoyable.
Holly Hester-Reilly:
Yeah, and when you were doing that, when you were re-architecting it to cut out all the duplicate code and make it simpler, and work better, did you take a lift-and-shift approach of, we're not changing any of the functionality, we're just re-architecting, or was there any amount of reassessing what was needed in the first place?
Shane Zilinskas:
Yeah, that's a great question. So first off, the system was very unstable. We needed to get to a place of stability. They would have people on call 24 hours a day to respond to system failures. You could get a system failure by a person pushing a piece of content.
Holly Hester-Reilly:
Wow.
Shane Zilinskas:
And when you have 150 some odd new sites go down simultaneously, just because one of their editors was trying to update a piece of content, it's a pretty big deal. So the first step was to get a new baseline, remove all the abstractions that we didn't need so that it was just easier to go in and maintain. The next step was to look at a new future, which was the way that everything was laid out was very rigid. So I worked with another member of the team to propose a solution that was a lot more flexible, as in...And when I talk about flexibility, I'm not talking about it from the software side, I'm talking about it more from the design and layout side. The editors only had one or two options in order to create a piece of content. So we created a system where they could drag and drop different elements, where they could change the layouts dynamically and it would actually be responsive for them, and actually have a good performance to the system. Because the system was incredibly unperformant. It literally understood every pixel of the screen, and would loop over every pixel and see if something needed to be there, and then they would just cache all that.
Holly Hester-Reilly:
Wow.
Shane Zilinskas:
Yeah, so there was no flexibility there. Things could overlap. So we created a system of components that could be deployed in a much simpler fashion.
Holly Hester-Reilly:
Okay, cool. And how did you measure success for that project?
Shane Zilinskas:
In a couple different ways. So, there was a few different stakeholders involved here. The upper management wanted a better future, and then the engineering team didn't want to be on call all the time, and then the actual editors just wanted to be able to use the system and not feel like they were potentially breaking things. So the success was measured, one, by being able to roadmap that plan of how do we take what we have today and provide a more flexible future that we're not locked in. So that was for the higher level stakeholders. And then for the engineers, and for also the content providers, it was that we have stability. We know we don't need to be on call all the time. We know we don't need to have somebody who's sitting there checking the site to make sure that it's still up and that the entire thing didn't go down. So those were the internal stakeholders, but also the external stakeholders were the actual users who were coming to the site. The site performance was absolutely atrocious. It would be like six seconds to load.
Holly Hester-Reilly:
Wow.
Shane Zilinskas:
Which when you have news articles, there's not much changing. It's not that dynamic. It shouldn't be like that. So, the ideal state for a page is for it to be feel immediate, which is less than 100 milliseconds. We crept down towards that. There's a number of systems in there that had to be overhauled and things like that in order to get it all the way down to that, but to deliver the content to the customer in a fashion where they wouldn't see our link and be like, "I'm going to go to the next one."
Holly Hester-Reilly:
Yeah. Cool. What was your next project after that? What did you go on to next?
Shane Zilinskas:
Yeah, so the next thing I did after that, I worked at an agency. So I worked on a number of different projects. Everything from building applications for remote parking.
Holly Hester-Reilly:
Sorry, did you say remote parking?
Shane Zilinskas:
Yeah, remote parking.
Holly Hester-Reilly:
What is that?
Shane Zilinskas:
I can describe this better.
Holly Hester-Reilly:
Okay.
Shane Zilinskas:
So, parking without an attendant.
Holly Hester-Reilly:
Oh, okay.
Shane Zilinskas:
So this was in 2014, and we just got Bluetooth IoT beacons. So building a system that you could drive up in your car, the gate would recognize who you are on the keypad. You would enter your pin code or bump your phone against it, the gate would lift and you could enter.
Holly Hester-Reilly:
Okay.
Shane Zilinskas:
So we could track when you were coming into and leaving the garage, and charge a car without actually having to press the button and take a ticket, which you actually see that in a lot of places now. But now, they're scanning your license plate as you enter.
Holly Hester-Reilly:
Interesting. I was imagining like, "Is there something I don't know about where we're parking cars remotely when you're not in the car?"
Shane Zilinskas:
I think Tesla's working on it, but I'm not sure they're quite there yet.
Holly Hester-Reilly:
Yeah, there's some people working on that, but that's a little more future state.
Shane Zilinskas:
Yeah, yeah, yeah.
Holly Hester-Reilly:
So it sounds like you've worked on quite a variety of different things.
Shane Zilinskas:
Yeah, and I've always enjoyed going to where the challenge is that can deliver value to people. So at that agency, I worked on probably 10, 15 different projects in the three years that I was there. Building prototypes, building medical applications, et cetera, which the next step was I left there, and my wife and I had bought one-way tickets to Europe, and then shortly after, started our agency.
Holly Hester-Reilly:
Cool. And that agency is ClearSummit?
Shane Zilinskas:
Yep.
Holly Hester-Reilly:
So tell me more about how you decided to start ClearSummit.
Shane Zilinskas:
Yeah, I was a little serendipitous, really. My wife and I were in Richmond, Virginia at the time, and we knew we wanted to be somewhere else. We wanted to go somewhere else for a while or something like that. And the next step for us in which we was to buy a house and settle down. So we both read Tim Ferriss' 4-Hour Workweek, and we were like, "I think we can do this." So we bought one-way tickets to Europe, and we're just backpacking around for a little while. And then people started reaching out to me, asking me if I could basically continue the work that I had been doing previously, which is building prototypes and mass market rollouts of applications. And so it started there, a little freelance, and then we ended up in Los Angeles after about a year, and then we started growing the agency from there.
Holly Hester-Reilly:
And what is the agency's focus now?
Shane Zilinskas:
Yeah, so we're a product-focused agency. Everybody in the agency is really obsessed with the user experience and driving value through the entire experience that the user has. We have designers on our team, we have product managers, engineers, and QA. And we focus on helping bootstrapped series A, B, and C companies, and also some mid-market companies basically take a project from zero to one. Helping understand what the stakeholders need in their team, interviewing their clients and who their demographic is, and understanding what they need and helping roll out those versions.
Holly Hester-Reilly:
And are your clients typically big enterprises? You mentioned series A, B, C startups, so I guess early, but are they typically working on enterprise software, consumer software, is there any consistency across it or is it just a big range of things?
Shane Zilinskas:
Really, the biggest consistency is just we're building direct-to-consumer products. So we've worked with... One of our clients in the past was Belkin. We worked with them for about three years on a project that they were incubating called Phyn, which is a IoT device that sits on your main waterline and comes into your house, and it listens to all your faucets, and it can tell you which one you're using, how much you're using, and if you have leaks in your walls, and help you understand where they are. So we've built a mobile application for that. We've worked with other companies and governments. So we've worked with the city of Richmond, Virginia to build an application for them so they could interact with their constituents to report problems in the city, to talk about their taxes, if they want to do that sort of thing.And so then there's also the bootstrapped camp or the seed companies who have just received their funding, who are looking to take a product to market. They have a concept, they have the pitch deck of who they want to go after, but they want to make sure they're delivering the correct features first. And then in between there is a mid-market, and the seed companies who generally already have some product-market fit, but they're looking to expand into another vertical. For example, they have a web application and they want to build out on mobile, so we'll come and fill that out. Sometimes, every so often there's some re-platforming in there as well. So it's typically a seed company that's moving into a series A, and they've gotten some traction, but the interface and the application they have isn't really working perfectly for their target personas. So we'll come in, understand who they're interacting with, how those people are interacting on the platform, design a new platform for them and re-architect it.
Holly Hester-Reilly:
Tell me more about that process. What does it look like when you come in and try to figure out how people are interacting with the platform, and what they need from it?
Shane Zilinskas:
Yeah. So a lot of times, the first step for us is really understanding the personas. A lot of times, the companies in that stage don't have their personas locked down. We prefer to get them down to names, so it's very easy to talk about them even sometimes what they do and where they spend their time. One platform that we did this with was a triple-sided marketplace, and it's in the food industry. And in the food industry, you have packagers, you have food producers, and you have distributors, and you need all three of them in order to get your actual product to market.But they all want to interact in very different ways, because they have all vastly different workflows. As a person who wants to go and set this up, and actually go through and deliver a new Clif bar, for example, that you want to be on the platform and you want to understand how these people are interacting. But as a manufacturer, they want the ability to be able to get information by email, respond via email. Other people want a dashboard where they can come in and check things off. It depends on their workflow. So a lot of it is understanding who that persona is, what their actual workflow looks like, and what their workday looks like, and making sure that we're building a product that fits inside of that. Because if we can't fit inside of their workflow, then they're probably going to not use the platform and adopt it as quickly as we would like.
Holly Hester-Reilly:
Do you have any stories of times where you're understanding the personas' workflow, or day-to-day experiences surprised you when you went out to find out what they were really doing?
Shane Zilinskas:
Yeah, I have ones interesting. The product that we were building was to connect grandchildren and their grandparents, especially in the modern age where most people move, they're not in the same cities anymore. How do we foster that connection between grandchildren and grandparents? And so we were tasked with building an application that four-year-olds could understand, but also 65-year-olds could understand. And the same thing showed up again when we built an application for the city of Richmond, Virginia, because we needed people, 18 to 65, to be able to understand and move through the application.So the thing that surprised us, I guess it's obvious, in hindsight, but for that application was to basically give the user only one or two calls-to-action on any screen, and to make those calls-to-action pretty large, which is great for the older audience because of visibility, not for children because their eyes are going to drift towards that. So the application had a very streamlined workflow, but it was interesting that both the four-year-old and the 65-year-old, when we did user interviews, that's the interface that they both responded well to. We thought we would actually need to have a slightly different interface for the two demographics, but it ended up that they both responded to the same interface well.
Holly Hester-Reilly:
That's convenient.
Shane Zilinskas:
Very convenient, especially when we're building these products and trying to get them to market quickly. If we can be convenient, it makes it easier to build. It makes it quicker to build. We obviously don't want to make it convenient just to make it be able to be built faster, because then it's not going to be adopted. But trying to find those shortcuts in a way is really helpful.
Holly Hester-Reilly:
Yeah, that makes sense, and it's certainly something I see as well. I guess I'm curious about this example of connecting kids and their grandparents. What did they actually do in the app?
Shane Zilinskas:
Oh, yeah. So the idea was to foster connection. And part of the issue with children is they don't know what to talk about with their grandparents, the grandparents need to suggest it.
Holly Hester-Reilly:
That's a problem for grownups and their parents too.
Shane Zilinskas:
Right. Yeah. It's also a problem for the grandparents sometimes. So like, "How do I talk to these children in this way?" So what we did is we had a set of questions that you could choose between, and they're all fun little icons. So you could choose animals or foods and you could tap on the icons, and you would tap on that and you'd get a question, and it would say, "What's your favorite animal," for example, or, "When's the last time you had ice cream?" And it was similar, in a way, to a Snapchat interface. It was a front-facing view and you would click answer, and the kid or the grandparent could respond to that, and you would create conversation threads. So the idea is to get the conversation going and then... Not necessarily to jump to the next question, use the next question when there's a lull in the conversation, but it allowed the grandparents to have prompts to the children where they could start asking questions and getting responses back.
Holly Hester-Reilly:
Yeah, that sounds cool. I think that no matter what age the kid is trying to engage with, just coaching them how to have conversations is a useful skill.
Shane Zilinskas:
Yeah.
Holly Hester-Reilly:
My kids are now almost six and eight, so I'm like, "Yeah." I very vividly remember those first conversations where you're like, "I'm actually talking to my child. She just asked me how my day was."
Shane Zilinskas:
Yeah, yeah. My child, I'll ask her why she likes something and she'll just say, "Because I like it." I'm like, "Okay."
Holly Hester-Reilly:
Yep.
Shane Zilinskas:
We'll get there.
Holly Hester-Reilly:
Yeah, exactly. I get a lot of that. The almost six-year-old certainly has plenty of that thing going on still. So like, "Why do you want that?" "I just want it." So one of the things that we talk a lot about on the Product Science Podcast is experimentation and user research. I'm curious if you could go into any more detail about the actual tactics of how you learned these things. When you, doing Zoom calls, where you had somebody using a phone, did you use certain tools? What did that look like?
Shane Zilinskas:
Yeah, so there's a couple different examples that I could provide. There's the examples of the user research, and then there's also fitting into actual product limitations and trying to figure out what those product limitations are. So a lot of times, what we will do is we'll do calls over Zoom and we'll walk them through the prototype, and we'll ask them to do simple steps, and just take notes on where they're faltering. Pretty basic user research in that way. We can also record the calls, and we have some tools that we use to transcribe the call, and so we can note where we're seeing frustration points, where we're hearing different ideas, and mark them and tag them against different personas so we can understand, "Okay, this persona gets it and they see all the value in it. This other persona isn't finding the value in the workflow."That's when we're interacting with users. We've built products before as well, where we actually have a lot of technical implementations that need to be worked around, where we don't know what we don't know until we actually start building it. Because we're working with hardware teams, we're working with machine learning teams. The hardware we think works a certain way, when it gets in the field, it actually doesn't. The ML thinks that they can deliver on these features, but their timeline's pushed so we have to create an experience with a segregated version of those features. And a lot of that comes down to understanding how each of those disciplines are providing information, their timelines, and then working back to an experience that still feels fluid to the user. And a lot of that is a much more agile. So week over week, producing a different version that tries to guide the user through, and seeing the hardware responds properly, and we're able to mitigate the risks on that side.
Holly Hester-Reilly:
Yeah, there's definitely a lot of different angles on it, but one of the things that you said there that actually piqued my interest is the way that you tag. Because I recently had a conversation with one of my user researchers about tagging and the usefulness of tags. I guess I'm just curious to learn a little more about how you tagged the interviews that you've recorded, and how often you go back and look at things based on what they've been tagged.
Shane Zilinskas:
Yeah. So generally, when we do the calls, we have a couple different people on the call from our side. We have somebody who's able to take notes or annotate in real time, and we also have the person who's guiding through the call. So we're tagging in real time, but we're also going back and synthesizing those results. We try to extrapolate the information and package it up, so we're not going back and reviewing the videos on an ongoing basis. But sometimes, that is necessary as well.
Holly Hester-Reilly:
Yeah, it can be tedious to go back and rewatch the videos. I also try to extrapolate the insights live while we're going so that we don't have to go back and one-to-one watch the thing, although thank goodness for the ability to speed it up.
Shane Zilinskas:
Yeah, absolutely [inaudible 00:19:20]. And also having multiple people on the call produces the need to necessarily go back and watch it, because the way we can have the conversation of like, remember when this person said that, and then we can talk it out and hash it out without having to rewatch the whole video. And if we're both unclear, then we can jump to that point in time.
Holly Hester-Reilly:
Yeah, absolutely. I also love having that debrief after with the multiple people who are on the call that, "Did we hear different things," or, "Did we pick up on different things in the conversation," but so interesting to see... One of the things that I love to do is to create a snapshot after an interview where it's just a one slide like, "Here's some key things from that interview." And I recently did that with a colleague of mine who created a completely different snapshot from the same interview, and he was like, "This is so fascinating."
Shane Zilinskas:
I feel like humans, a lot of times, have to hear things three times before they see the same thing. So, yeah. It's really important because we all come to it with our different perspectives and lenses, and we're trying to understand. We have multiple stakeholders and personas, and we're trying to empathize and be in their shoes about how they're seeing that. But a lot of times, we still put our own filter on it.
Holly Hester-Reilly:
Yeah, we do. And it's interesting what different goals look like, I think. I often look at things with the lens of how much can I cut from the plan. I'm such a big fan of simplicity and reduced complexity, that I'm like, "What in this interview told me that I can cut that thing that we were thinking we needed," and somebody else may look at it and be like, "What are all the new exciting ideas that they gave me a reason to think I should pursue?" I'm like, "Yeah."
Shane Zilinskas:
It's a little terrifying when it's look at all these new ideas that we can't pursue, because then you go from something where you can ship it in a few months to this is a yearlong roadmap. I would definitely put myself more in the camp with you. Let's cut anything that's not at extreme value to the user or the business, and obviously, has an inverse relationship to the amount of time and ship it.
Holly Hester-Reilly:
Yeah, exactly. So what are some things that you've learned along the way, especially since you started your own agency and have been working with different clients. Are there common challenges that your clients often come to you with?
Shane Zilinskas:
There's a large amount of our clients who come to us specifically for building mobile applications. We find that there's a lot of teams out there who are really good at building web applications, but then, when the product team or their engineering team looks at mobile, they're not as up to date on the workflows and how people are expecting interactions, and things like that. There's a lot of nuances in there which are slightly annoying from a product side that you have to work around. If somebody didn't give you camera permission, then you tell them to go in the settings, you can guide them through that, and then when they come back in the whole app restart. So grounding them on where they are now, do they want to still go do that, et cetera. A lot of companies come to us because they're opening up a new vertical like mobile or something like that.
Holly Hester-Reilly:
That makes sense. And I could see they're being in that special skill in being used to working with the interactions and settings that they have to deal with within the phone.
Shane Zilinskas:
Yeah, and it's also screen size. We have to condense information a lot more into a smaller screen size. And when you start looking at all the different Android devices, you can start getting pretty limited in the amount of screen size and the things you want to communicate. So, really understanding how to put that information in a dense way on the device, and also the things that people don't want to do on a phone. Understanding that as well. For example, using Google Sheets on your phone, you can do it, but that's not really where you want to do it or figuring out.
Holly Hester-Reilly:
It's pretty tedious.
Shane Zilinskas:
Yeah.
Holly Hester-Reilly:
I've tried.
Shane Zilinskas:
Yeah, you sit on the couch for two minutes and you're like, "I'm going to go to my laptop now."
Holly Hester-Reilly:
Exactly.
Shane Zilinskas:
Yeah. So just understanding where user gets fatigued in applications because of things like that. Users don't want to dig deeply into data, so how can we basically give them the best of, in a way, allow them to do jobs that need to be done inside that application, and then maybe leave a different experience for the desktop.
Holly Hester-Reilly:
Yeah, that makes sense. And what is your team's interactions like with the desktop counterpart when you're brought in to build a mobile thing?
Shane Zilinskas:
Yeah. So a lot of times, the first... For us having high communication and lots of touchpoints is really important. If we can't empathize with the users, empathize with the stakeholders, then we're going to miss the target. A lot of times, that's just sitting down with stakeholders, understanding the jobs that they're currently doing on desktop with how the application functions for them and the value that they're looking for, and then looking for, in mobile, things that they would actually want to do while they're on the move. So again, you're not going to want to do the same things on a desktop computer as you do on mobile. You're probably... Hopefully, you're not driving, but you might be in an Uber, you might be walking around at a Starbucks or something like that, so bringing that information to the surface. So we have to understand the things that they might be doing when they're on the move, and not actually in front of a desktop that are also providing value, and then building an application around that.
Holly Hester-Reilly:
Yeah, that makes sense. Where do you see your teams going next? Is it continuing to work, focusing on mobile stuff? What does that look like?
Shane Zilinskas:
We do web platforms and mobile as well. It's just, a lot of times, when we're building a mobile application for a seed company or a mid-market company, or something like that, there's likely going to be a web counterpart to it. We don't start them both at the same time, generally, because there's a lot of learnings that we can find just from user testing with a real application that we don't want to have to rewrite two things, stagger those a little bit. So, yes-
Holly Hester-Reilly:
Which one do you usually start first?
Shane Zilinskas:
It highly depends on the persona that we think we can deliver the most value to. So we recently built a platform for... I won't go into the actual company because it's under NDA, but we basically built Venmo with a financial overlay to get insights into the transactions for compliance reasons. So the first thing we needed to do was actually to get the users on the platform to be able to transact money, and they're doing that on the go, and on the move, right?
Holly Hester-Reilly:
Yeah.
Shane Zilinskas:
So we built the mobile application for that first, and we knew we could get the financial insights afterwards. So then, we built the web application to give the financial insights into those money transactions.
Holly Hester-Reilly:
Yeah, that makes sense. I guess one thing that talking about personas and what we're going to build first makes me think about product strategy. I'm curious. How do you think about developing a product strategy, and is that often given to you by your clients or are you often building that as well?
Shane Zilinskas:
Yeah, a lot of times when we talk with clients, they will have an idea of what they want. Like, "I want to build a mobile application," then a number of times is you should actually build a web application for these number of reasons. So the very first step for us is understanding what they're actually trying to accomplish, and then we define where we should build. So for example, there's some clients who will come to us, it's not as much now, in the past, 10 years ago, everybody wanted a mobile application, right?
Holly Hester-Reilly:
Yeah.
Shane Zilinskas:
Like with this launch of the mobile application on the App Store.
Holly Hester-Reilly:
I remember that.
Shane Zilinskas:
Yeah.
Holly Hester-Reilly:
I remember being in a lot of meetings where an executive was like, "Let's hold a mobile app for that." And I was like...
Shane Zilinskas:
Yeah, right. Mobile is great. You can get certain interactions and create an experience that you can't, if you just have a mobile responsive web app. If you get it right on their phone, obviously, they can bookmark it, but it's slightly different. You get push notifications, you can fake push notifications now with web push. But there's also the counterpart to web, if you have the application on web, you can start doing more interesting things. You can build out public facing pages of the application so that you start getting indexed by Google.So you start getting domain authority, people can search, and you start appearing in search, which starts to lead to more organic growth of the company as opposed to if you're releasing a direct-to-consumer application in the App Store, then you're building a marketing page for it, and you're also doing App Store optimization, but you're not getting all that organic search that you could be in other ways. So a number of times, it's maybe we should do web first because it's going to help create a more organic growth to the company that you would be spending on ad spend or something like that.
Holly Hester-Reilly:
Yeah, so it sounds like you definitely get involved in the strategy about where should we start. What about the strategy in terms of what personas we should be focusing on and which of their problems we should be solving?
Shane Zilinskas:
Yeah. This is the first month when we engage with any client, we call it product liftoff, which is finding the fit, understanding the personas, mapping them out, mapping out their jobs that need to be done, right?
Holly Hester-Reilly:
Yeah.
Shane Zilinskas:
And so in one way, what we do is after we talked to the stakeholders, after we've maybe interviewed some of the customers who'll be using the application that we're going to build, et cetera, what we'll do is we'll start building out user stories so that we understand what we would actually need to build to accomplish that at a high level. We view our documentation as a living document that we are constantly going back to as we're talking about features. So a very brief description of what we're building, and then what we'll do is we'll put them in a feature prioritization matrix a lot of times, and we'll work with different stakeholders to weight those features in different ways.So it's, generally, when you're going to have the value that you're driving to that persona or that customer, which we can collectively decide the weight of that. We also have the value that we're driving to the business. So a paywall would be 10 on driving value to the business, but not so much necessarily to the customer. And then we have the inverse weight, which is the time to build out this feature. Like, "How long is it going to take us not only just to build it, but to analyze it, and any learnings that we might have to tweak on the backend in order to get that feature correct." That, in general, just doing that generally helps get the stakeholders aligned on where we see the most value, where everybody sees the most value, because it's a collaborative process. We'll come in and say, "This is what we think," but we work with the stakeholders as well to reweight things and change things around. So through that feature prioritization matrix, a lot of times we're able to figure out which features we want to build first.
Holly Hester-Reilly:
Got it. Okay. I think the last thing that I want to ask you is I always ask my guests if they have advice for someone who's following in their footsteps. So in your case, I guess anybody who's looking at going off and starting their own agency, or starting as a consultant or something, but leaving the mothership, what would you say to people who are thinking of doing that?
Shane Zilinskas:
Yeah, I think you always have to be hungry. You always have to be looking for the next challenge and the next thing you don't know that you don't know, so that you can learn it and you can approve upon it. If you're running your own business, there's going to be a number of things that come out at you from left field and understand, and you won't know even how to deal with that challenge. And so, being hungry enough to learn what that challenge is, how to tackle it, and in addition to that, finding very strong mentors that you can talk to and that you value their opinion on because they've also been there before. So being able to have that conversation, and them, being able to sometimes offer you through a five-minute conversation, enlighten you to a perspective that you didn't have before, that really changes everything.
Holly Hester-Reilly:
Yeah, adhere to that. Where can people find you if they want to learn more?
Shane Zilinskas:
Yeah, you can find us at our website clearsummit.com.
Holly Hester-Reilly:
Awesome. All right. Thank you so much for your time today, Shane. It was a pleasure to talk to you.
Shane Zilinskas:
Thanks, Holly. It was great talking to you as well.
Holly Hester-Reilly:
The Product Science Podcast is brought to you by H2R Product Science. We teach startup founders and product leaders how to use the product science method to discover the strongest product opportunities and lay the foundations for high-growth products, teams, and businesses. Learn more at h2rproductscience.com. Enjoying this episode? Don't forget to subscribe so you don't miss next week's episode. I also encourage you to visit us at productsciencepodcast.com to sign up for more information and resources from me and our guests. If you like the show, a rating and review would be greatly appreciated. Thank you.
.png)
