Dave: Hey everyone, Dave here with another episode of the Philly Tech Connect podcast. Today, I’m speaking with Ryan Long, the founder of Peak Solutions, a software development company focused on supporting entrepreneurs in various stages of growth to design, build, and launch products. He’s worked with Nike, and has had experiences as a startup founder and as a CEO of a medium-sized business in the DC area. But now, we’re looking to have him in Philly. We’re going to be talking about building highly effective tech teams, what is the right call to work with an agency or to build in-house, and anything else we kind of come up with. Ryan, how are you doing?

Ryan: Dave, I’m doing great, and I can’t tell you how excited I am to be here with you and be part of your podcast. I love what you’re doing with PTE and the community you’re building, especially in the Philly area. I think Philly doesn’t get quite enough recognition for the density of entrepreneurs and startups within it. So, glad to see what you’re doing. Thanks, man, I appreciate that. It’s great to have you in the community as well.

Dave: Let’s talk about, you know, I guess the early days before you have the tech team in place. A lot of people have ideas; they don’t have the technical knowledge and maybe they’re looking for a CTO or they may be considering an agency such as yours. When is the right approach to how to go about this? You’re a founder, you have an idea, maybe have a marketing background, or you’re just someone who’s experiencing that problem. Is there a right approach to whether you work with an agency, whether you bring on someone as a partner, or whether you hire somebody? How do we kind of go about making that choice?

Ryan: Dave, right for the hard question. I don’t know that there’s a one-size-fits-all answer here, but what’s really important as an early entrepreneur is to take the time to understand your partners, whether it be a co-founder, bringing on a fractional CTO, or parsing out some of that work to an agency. It’s really important to make sure that your values and objectives align with the person or team you’re partnering with, and that can be really challenging in the tech and startup space, especially for non-tech founders. There’s a lot to navigate, a lot of new roles within that, whether it be developers, designers, product strategy. There’s a lot to navigate and so finding someone you trust who can help you understand how each of those roles fits within your ecosystem and is going to help you get to product market fit and product launch, that’s really important when you’re evaluating an option.

Dave: You know, we know that the tech skills are important, but what are the other factors that we need to take into consideration? You mentioned at a high level that they align with your goals and maybe they align with your vision and things like that. When we’re actually having those conversations, what are maybe the things we should be asking or paying attention to signal to us that we’re maybe going to be working with the right people?

Ryan: That question isn’t necessarily specific to tech, but to any partner. Understanding where they place their values, what they feel is important to them, and how they work with others are the soft skills that really make a difference. The startup world is super competitive and sometimes that can bring out the worst in people because they’re hyperfocused on an outcome or getting a promotion or finding that unicorn solution.

Dave: I used to work with a developer back when I had my first SaaS, and I don’t really have a technical background—I took like a coding class in college once. So, I sort of knew a little bit about how to think about tech and approach it, but I didn’t necessarily know what I was doing. I ended up working with this developer who had really poor soft skills. Technically, he was really sound and he convinced me that he was really capable and was the right person to go with, but he was a difficult person to work with. He wasn’t particularly communicative, wasn’t that nice, and I found myself in a bit of a bind as a founder because the more I worked with him, the more I felt kind of tied to that relationship. It’s like, “Oh, this is Jacob, he’s already been building the product for months, he knows it inside and out.” The idea of starting with somebody new was really daunting, but at the same time, these soft skills that he didn’t have, I knew they were never going to get better. They just were what they were, and he wasn’t really going to make an effort to improve in that way. Does that story resonate with you? Have you seen kind of experiences like that, or what are the ways in which you try to differentiate yourself in that area?

Ryan: Dave, that resonates with me entirely. I lived that in a previous startup life, and maybe that’s what motivates myself and my team today to do differently. Whenever you’re working with a new partner, having that discovery session upfront to set expectations, understand what the scope is going to be, what the timeline is going to be, and what those key deliverables are along the way is going to help set you up for success. I also think bringing in a UX designer early in the process is a sign of a well-rounded product development team because you know they’re going to place a heavy emphasis on your end user and collaborative thinking. That’s a great signal for a tech partner to bring in.

Dave: I love that suggestion. I think it’s easily kind of overlooked. A lot of people don’t realize that a developer who maybe is responsible for front-end, back-end coding is not necessarily a designer. And that may sound obvious to yourself, maybe to some people, but it was not obvious to me years ago. And they would kind of produce these results, these pages, and stuff I go, “This doesn’t really look that nice, like this looks kind of ugly.” But it worked, it was functionally kind of worked, and that was when I understood that that was a different skill set. When you’re building a business, certainly a product like you said, having the end-user in mind is sort of always should be kind of always like the guiding light that sort of dictates what you do. So by having that user-experienced person, it’s literally someone whose job is to be thinking about the perspective of the user. And I think that’s just so important, like so many tools we use nowadays you kind of just kick yourself, “I can’t why they do it like this, it’s just not at all very friendly.” It’s a turnoff to what otherwise could be a great software, you know.

Ryan: Don’t get me wrong, it’s very important to have a talented developer behind the scenes doing the work, but your customers—they’re interacting with that user interface. How they feel when they use your product is directly dependent on the user experience and the ability of that UX designer to put themselves in the shoes of your customer. How do I want to feel as I’m navigating through this journey, how do I want to feel when I leave this site or leave this app? That’s what’s most important, no different than shopping online on nike.com. How you navigate through that checkout decides whether or not you’re going to buy. The same thing is true when you’re downloading an app, using a service—it needs to be a great experience.

Dave: In the world of marketing, where I generally live my day-to-day, there’s a lot of different channels, things like social media, SEO, paid advertising, etc. If you’re a marketer, you probably have an awareness or an understanding of many of them, but you may not be really like a specialist or particularly skilled in all of them. I for one have not really done much with like paid advertising campaigns. Is it kind of the same in tech, you know, and what are some of the major differences you know? I know there’s lots of different coding languages, fine, but to my understanding, like the same app could, could, could in many ways sometimes be coded on multiple different languages. It’s not always like the biggest decision to make, but are there bigger decisions around whether it’s B2B or B2C, or whether there’s an e-commerce portion or you know, is that maybe a factor that really should be considered?

Ryan: Dave, and I had this conversation yesterday with someone who’s in marketing and in digital advertising. The world of marketing and the world of product development are very, very similar. It’s about identifying that product market fit, about identifying what your customer is going to want and how to speak to them, how to engage with them and meet with them where they are. So there’s a ton of overlap in skills and an early process of identifying where you want the product to be long-term. The North Star vision of where you want to get to, that’s going to inform a lot of those decisions you were talking about about what tech stack or what programming language or what infrastructure is going to be used because you’re right, a lot of them are interchangeable, and it’s how you piece them together to get to a solution that’s going to change.

Dave: You know, when I talk with clients in marketing, we’re often trying to get them to understand the bigger picture of what we’re trying to do, the longer-term implications, and potential results that we can drive, and not always to be kind of focused on little things day-to-day. Sometimes people maybe come in with the wrong mindset, I guess, and I wonder when you are talking with a founder, they’re evaluating their path for tech, do you find people sometimes are having the wrong priorities? And if so, again, what are the areas where people often are overlooking or not paying enough attention to in terms of what’s going to really matter for them?

Ryan: Great question, Dave. I think one of the most common mistakes I see is rushing to development too quickly. When someone comes to me or our team and they’re looking for our services, they want help building a product, building an MVP, or improving their software, it feels like it should be a light switch moment where we just start development and boom, here’s a piece of software, and not enough time is spent early on in validation, in user research, and really understanding the problem you’re trying to solve. Until you have a crystal clear idea of the problem and how you’re going to solve it and how that adds value to the customer, you can’t start anything because it’s a waste of time, it’s a waste of resources. That’s a big one.

Dave: Yeah, that is, that’s the big one right there. You just said it, and it really resonates with me as someone who’s frankly has built several things that nobody needed, and I see this all the time as well. If you go on any website like a Flippa.com or something like marketplaces where people are kind of selling tools, it’s just a graveyard of tools that people have built that have no users, no revenue. It was somebody’s kind of idea or passion project, and they said, “I’m just going to build this,” and then like nothing really comes of it, and it’s because of the lack of time spent in the user research, in the problem-solution kind of fit. It’s totally underappreciated. I can’t stress this enough, so I’m really glad that you brought that up, to that point.

Ryan: Dave, a common term that’s thrown out there is MVP, minimum viable product, and the idea is the smallest or least complicated form of the solution you can get out there to start getting validation and real user feedback. That term is thrown out there a lot, and it’s not an endpoint, it is the starting point. So the quicker and cheaper you can get to that MVP or that point where you can learn and iterate the better. So spending a ton of time upfront in user research, inexpensive prototyping, and a very narrowed MVP is how you get to the product-market fit, how you get to those really valuable solutions because you’re able to get feedback.

Dave: Yeah, no, like super, super well said again. I just, I don’t know if we all sometimes really understand we hear these things, but like, I don’t think we really kind of understand it, you know? There’s a guy in the community, I’m not going to name names or whatever, but there’s a guy in the community I’ve kind been working with on an app that, you know, is talking about maybe matching people at events and stuff like that, and he’s building, building, building. He’s like a developer by trade, so it’s sort of his natural inclination to build things, and, you know, I think the other day kind of came to me, he’s like, “You know, I want to take a step back and I want to just go to an event and see if I can just match people up manually. You know, like do a survey, find out who they’re interested in meeting, and just literally just manually kind of pair people and just see what the experience is like. Do people actually take the time to fill out the survey? What types of responses do they provide? Do they actually meet with the person at the event?” Like, you know, just some real basic market validation and research. And it’s cost them nothing basically, except for some time or whatever, but that’s the name of the game, and he’ll get some great insights from that that’s going to help, you know, potentially shape the product if he decides it’s something worth going forward with. So, this, that was a really, I can’t think of a better place to kind of end the podcast on because this, this I think was really the driving point. So there’s no need to edit this. I feel really good about where we ended up. For people that do want to learn more about you, your services, you know, get in touch, how can they do so?

Ryan: They can find me on LinkedIn, of course. Our website is peaksolutions.com. That’s P-E-A-K or, or you can magically make it appear right here.

Dave: It will definitely be in the show notes and in the description. How about that?

Ryan: Sound good. Thanks for having me, Dave.