NOEL: Hello and welcome to Episode 31 of the Tech Done Right podcast, Table XI's podcast about building better software, careers, companies, and communities. I'm Noel Rappin. I've got a couple of new things in the intro this week that I'm very excited to tell you about. First off, Table XI is now offering training for developers and product teams with topics including testing, improving Legacy JavaScript, career development, Agile team process, and a couple of other things. Many of these workshops are going to be led by me. And if you want more information, you can email us at workshops@tablexi.com. We've talked about Table XI's career growth strategy on the show a couple of times. And by the time you hear this, we will have a website with information and techniques that are absolutely free, and that you can use to improve your team's career growth and goal strategy with very little investment on your team's part. You can find that at http://stickynote.game. Again, we'll have some free information at http://stickynote.game. Finally and more personally, my book Rails Test Prescriptions is, as you listen to this, either actually out in the world or very close to being out in the world. The book is up to date with the latest Rails RSpec and MiniTest features and has some great non-dogmatic content on how to get value from testing your Rails applications. You can buy Rails 5 Test Prescriptions at pragprog.com or wherever fine technical books are sold. Today on the show, we have Neil Patel. Neil's a digital marketer and the co-founder of Crazy Egg, Hello Bar, and Kissmetrics. He's been called one of the world's best online marketers. He's also a serial entrepreneur who's worked to bring a lot of products into the world. I wanted to talk to him about that process, how he comes up with an idea, builds it out with a design team, and then interacts with the development team to make it real, and how he refines it by talking to users, looking at metrics, and iterating over time. Neil works differently with his developers than some of the other product and marketing people we've had on the show. He's got a different perspective on how to build products, and I think you'll find it interesting. Here is our show with Neil Patel. Neil, would you like to introduce yourself to everybody? NEIL: Hey everyone, I'm Neil Patel, serial entrepreneur and marketer, blog at NeilPatel.com, co-founded Crazy Egg, Hello Bar, a few other analytical companies, and I just help people grow their businesses and get more traffic online. NOEL: Great. And what I wanted to start talking about is through all of your serial entrepreneurship, you've worked with a lot of different developer teams and a lot of different developer consultancies. And I wanted to talk a little bit about what makes a good relationship between you as the entrepreneur and the development team that you're trying to grow the business with. So, why don't we start with what do you look for in a development team or in your relationship with a development team? NEIL: Yeah, I'm a bit different. A lot of people who look for dev teams look for how much are they paying per hour, what's their skill level. And I do look at what their skill level is. I more so look at how good are they, how fast are they, and how hands off can I be. So for me, the most important part of the dev shop is the ability for them to figure out what to do and they should be able to know what to do that's best for the business. That's what I'm looking for. NOEL: So what kinds of things do you do in your initial interaction with a team to try and ramp them up to the point where they do understand your business vision? NEIL: Nothing. I only pick dev shops who can figure out on their own. It costs more money but let's talk about my interaction with you guys. I had an intro call for maybe 30 minutes to an hour, max. And then you guys are off to the races. Sure, there were weekly calls, or you dealt with the project manager on my team. But you guys would do research, you guys would tell us what kind of solutions, what people have in the marketplace, what we should be doing, et cetera. And that's what I typically look for. And being blunt, you already know this, you guys aren't the cheapest per hour but that process fits really well with me. I'm looking for speed and I'm looking for someone who can figure out everything on their own because I don't look at it as how much I'm paying per hour. I'm looking at how much I pay for the output. And that's been a good experience so far with you guys. And maybe I'm a bit different because I like being hands off but that's really why I pick dev shops who can figure things out on their own. NOEL: From your perspective of being hands off, what do you like to have as sort of reassurance that things are going well over time? Like how does that relationship develop? What makes you feel like the team is getting it? How do like teams to report that information back to you? NEIL: I can see it in the product. It's that simple. If I can't log into a staging URL or the live website, and I can't see things working, then for me, it's not working. It's not up. There's something wrong. NOEL: Are you looking then for teams that have developers with experience building a lot of these? I guess what I'm saying is what kinds of things have you seen be successful in this? Is it developers with a lot of experience? Is it teams that have strong project or product management internally? Is it people that are...it seems like you're not looking for communication skills exactly. NEIL: To clarify, I am looking at communication skills. If you have bad communication skills, there'll be delays and they don't ever tell you why. I more so looking for, I pay you X dollars, you told me you're going to give me Y, give me Y and give me Y without the delays. That's it. And that's fair because if I'm paying a premium, that's what I expect. I'm also looking for people who are smart, experienced, and they can figure things out on their own from doing research, to loving the product, to loving the idea. And they just want to get it out because they love seeing that progress and momentum themselves as well. And of course, what I've found is, this is very effective when you try to go after small teams, if you go after big teams, this doesn't work too well because big teams cause too many delays. NOEL: So what, in your experience, causes big teams to have delays? NEIL: It's just too much overhead. It's a Facebook rule. If you can't beat a team on a pizza, then something's wrong. NOEL: So, I guess it's important for you then to have developers that really are enthusiastic about the idea itself. NEIL: Yes. I want them to be enthusiastic about the product, like it, believe in it because if they don't, then they're not going to do as good of a job trying to figure it out on their own. Keep in mind, none of this really works well without a good project manager. Without a good project manager, everyone's running around like a chicken with their head cut off. NOEL: Where do you normally put the boundary between you and the development team? Do you normally own the project management? You normally see the product vision. How much of the details do you typically want to own on your side? NEIL: Internally, we always have one person that just manages the whole process and they just communicate with us on how things are going. And yes, that person will help direct vision, manage expenses and budgets. And on your end, of course, you guys usually are dev shops. Most good ones also put in a project manager or a product manager or whatever you want to end up calling it. I don't know what the right term is. And they just make sure that everything's going on track. NOEL: What do you see as an early red flag that things might not work out? What has been, in your experience, a bad indicator of future results? NEIL: Missing deadlines and making excuses. If they continually miss deadlines and continually make excuses, I don't really care because I didn't give them the deadlines, right? NOEL: Yeah, that was my next question was where does the deadline...in the way that you work with the dev teams, the dev teams are setting the...it's a deadline against their own estimates, right? NEIL: Correct. NOEL: In the process of creating that estimate with the dev team, do you do it in stages or so that you see how much trust you can have in their estimates over time? How much information do you like to get it upfront? NEIL: No, no, no. Everything is all about using the MVP, the Eric Ries Lean Startup Methodology and just like, iterating, going really fast, and doing it in very small stages. I don't want one week timelines. I want few day timelines. NOEL: It's on the development team to break down your vision into two or three, into small few day level chunks that they feel like they can deliver. And then start to deliver that on a sort of a routine rhythm that you both can get used to. Is that what it feels like when it's going well? NEIL: Yeah. If they keep meeting the deadlines, they can figure out the vision and they can figure out without having too many technical glitches. Because even if they meet the deadline, it does not mean it works perfectly. But yes, assuming they're into it. They're moving fast, there's very little errors, and they're being thorough and they're testing and all that kind of stuff. Then you keep expanding the scope and you go from there. But I test dev shops out in small chunks. If you do anything too big, you just going to lose a lot of money. NOEL: You start off with a small piece of what you hope will be a larger project? NEIL: Correct. I remember one of my first times hiring a dev shop. What ended up happening is I paid them and they started the project and within 30 days. They helped me scope out everything beforehand. And they're like, "Oh, this is going to cost three times more than we estimate." I'm like, "All right, you guys are useless." NOEL: What? Was it more complicated than they thought or they had made them some mistakes early on? NEIL: No, more complicated than they thought. They're good guys. It's just I didn't work with them again because it's like, "If you scope everything out with me ahead of time and then you tell me, we agreed on a budget, we do a contract and now you tell me it's going to cost like two or three times more." It's like, "I don't care. I'm done with it." NOEL: You come to the dev shop with a vision. And then there's something that must be going on with you and your team. NEIL: No, I don't come with a vision. I come with a vision, designs, wireframe, and then we go and develop. NOEL: Right. NEIL: If you are not scoped out then wasting your time with the dev shop. I'm big on scoping it out before? Of course, things change. You should scope it out and do all the wireframes and designs as much as possible. NOEL: So what is that process? So that is a process that I don't normally have a whole lot of visibility in because I normally come in as a developer. So, where do you start? What makes you think, "Oh, this is something that needs to exist in the world." And then, what are the first couple of steps that you do towards beginning to flesh it out? NEIL: I usually do the flesh it out. Internally we hire a design company, someone who actually produces wireframes or prototyping. We tell them what we want, they end up wireframing it. We go for revisions of it to try to make it more usable. We get feedback from customers, we continually fine tune it and tweak it, then we get into design. And once it's designed, we send it to the developers. NOEL: First of all, you come up with some sort of idea. Like what would be a...pick a product for you to talk about. NEIL: Sure. Let's make an SEO tool that helps you optimize and analyze your size. That way, you can get more search traffic. NOEL: Okay. You started with an idea that this was something that you were doing. Were you scratching your own itch here or was it coming from something that you saw people struggling with? NEIL: Both. NOEL: So once you had that, you start doing wireframes then...testing the wireframes, are you doing formal UX kind of testing? NEIL: No, no. We just talk to people and find out what they think. NOEL: Yeah. NEIL: We're not dealing with user testing or anything. We're not that. At least I'm not that sophisticated. My business partner, Hiten Shah is really much more sophisticated than me but I'm like quick and dirty. NOEL: After you get a couple of people to sort of prove the idea out, you go from the wireframes to the designs. And at that point, the designers...you have the designers work in advance of the developer team? NEIL: Correct. Yes. NOEL: Does that mean that most of the developer teams you work with, you don't expect them to have design resources at their disposal? NEIL: No. I expect them to because UI and stuff changes as you develop because you find that certain things can't work and certain ways are not as usable. NOEL: How sophisticated then or how complete do you normally have the designs? What's your design deliverable to developer team normally? NEIL: My design deliverable to developers is wireframes, scope and design completed. I usually even code up the frontend of the design as well. NOEL: The complete design, is it delivered as CSS or is it delivered as a screenshot mockup, screen layouts? How do you like to work in that? NEIL: No, design coded and it's off to them. If they want to recode it using some framework instead of basic HTML and CSS, that's up to them. Like if they use React or whatever it's called. But I keep it really basic and simple and provide them the designs that are even coded up. NOEL: So the developer team does its work, it moves forward. How do you take that product out into the world and try to build up an audience? What are some of the techniques that you find effective? NEIL: Launch the product on Product Hunt, push it out on there, push it out on like Reddit, Facebook. Go find your closest competitors. You may not have a direct one, but go find the closest competitors, go to hrefs.com, put in their URL, and you'll see who talks about them. Literally, just manually hit up each of those people and try to get them to talk about you and promote you and discuss you as well. So, it's brute force outreach. Same thing you can do with PR. You can look at sites like Tech Crunch and Mashable and Business Insider, which journalists and authors are talking about specific somewhat competitive products. And then pitch them on talking about you, like it's a grind. But that's how you market. Marketing is not like the magic wand where you wave it and you're instantly popular. It's this hitting the pavement and doing thousands of little things that add up to something big. NOEL: What's changed about that process in the last year or so? Like how is that process changing? Is it harder to get your message out now? NEIL: It's not harder. There's more channels. It's just more competitive in which if your product isn't good, you're going to have a hard time getting your message out. If your product's good, you won't have as hard of a time because there's so many mediums and channels. NOEL: I guess my experience is that it's increasingly hard to break out of the noise in terms of getting people's attention over channels that would have been more effective a couple of years ago. Do you find that to also be the case? NEIL: If your product is amazing, no. If it's crap, yeah. NOEL: How do you convince people that your product is amazing? NEIL: Like what did Slack do? Slack didn't tell everyone, "Our product is the best, use it." Their product just is really good. A good product markets itself. Everyone thinks about, "Oh, let me have the best marketer and they'll promote it." Yeah, you can do that but it still doesn't give you the best product. NOEL: I mean, you do products that are like SEO optimization and things like that. You must think that those techniques have some benefit at least at the margin in getting your products to people's attention. NEIL: Yeah, of course. You can do SEO, you can do pay-per-click advertising. But again, those are like...think of them as bandages. Yes, you should do them, but doing them with a crap product won't guarantee success. Doing them on an amazingly good product will guarantee success. NOEL: How hard do you find it typically to get those people to pay attention to your new product? You say like find the people are talking about your competitors and get them to start talking about you. That becomes a part where… I had this conversation with somebody who specifically talks about developers marketing content. And we were talking about things that are effective and things that are comfortable. Does it help to have a personality where you're comfortable with that sort of outreach? Is it challenging? Do you find the targets of that receptive? How does that play out? This is a part of the product world that I don't normally touch and I just don't have very strong understanding about how it works or how it feels from the point of view of somebody who's practicing it. NEIL: Usually, if people are using your product and they're getting value from it, you're good to go and it's easier to promote. If someone signs up you product and they're unable to figure out how to use it or it's just too complicated, the onboarding flow is messed up… and most of them revolves around the onboarding flow, then you're shit out of luck. And that's typically what ends up happening. With good onboarding flow, people find value within the first few minutes of using it, you're good. If it's too long to find value even if it's a great product, that's where you're not going to do. NOEL: What kinds of things you like to have in an onboarding flow? You mentioned Slack and I remember, one of the things I remember about Slack the first time I used it was that they had a very nice onboarding flow, the tutorial that sort of walked you through all the different pieces of it. Certainly, we got a lot of requests to do similar things. Are there specific things that you like to put in your products to improve that kind of first experience? NEIL: Yeah. Tutorials, walkthroughs, they're all really useful. My co-founder Hiten Shah taught me this as well, putting like a get started area in your onboarding and like a checklist and list what they need to do and complete in that order. That helps quite a bit. So just doing things like that really help improve the experience because people know what to do. But the key is to give them some sort of benefit as quick as possible. If it takes too long, you're going to lose people. NOEL: Is thinking what that initial benefit is part of your initial idea with a product or is that something that emerges as you see your first test users kind of work with a tool? NEIL: It's usually as your test users come through, you can keep tweaking and adapting. And it could take many cycles before you get there. It's not that easy to just have amazing onboarding flow. Even if you're an amazing product person or developer or designer, you usually are going to have to keep tweaking and testing until you get it right. And then once you get it right, that's when you push the pedal on the marketing efforts. NOEL: Have you ever been excited by what users found interesting or exciting about a tool wherein you thought the real value was going to be in some other? NEIL: Yeah, of course. Because when you find the real use cases and why people use it and why they're excited, you're then able to take that and push your product or center on that so then you're delighting more people. NOEL: Yeah. So, what's an example of that? Were you discovered over time? What was exciting? NEIL: Sure. So we have a keyword tool and we thought people just wanted more suggestions. What we found is they didn't just want more suggestions, they wanted to know what keywords to target that were the least competitive when it came to SEO. And once we learned that then we were able to focus the results around 'hey, here's what you should target' versus giving them a thousand suggestions. And then from there, people started really focusing and started using the tool because it was much more actionable and they didn't have to go through hundreds and hundreds of results. NOEL: How do you know when you found that nugget, when you found that that thing that makes the product great or that little detail that really has helped it stand apart? NEIL: Well you just keep testing and iterating until your numbers, your goals or your KPIs are going up from daily active users to people doing page trials to paying, whatever it may be. And it's not always clear but through a lot of iterations, you'll figure out what people liked or what they don't. NOEL: Have you ever had a case where you just never found it? How long do you put cycles into something if you're not sure if you've actually found the heart of it? NEIL: You can end up putting a year into something. You can put less, you can put in more. It's really up to the entrepreneur. I don't like wasting more than six months but that's just me. NOEL: Once you have users, do you find that dealing with users and making sure that their needs get met over time do your find that's a different skill set than acquiring the users in the first place? NEIL: Yes. Meeting their needs, making them happy is definitely different skills than acquiring. Acquiring is more like marketing. I would say meeting their needs is more like product focused. NOEL: So, what kinds of things do you do with a successful product to try and keep up with the users and their needs? NEIL: You just keep interviewing people, you keep looking at competitors, you keep serving people. You just got to stay on the market and not necessarily just look at what they need but more so where the market's going and try to adapt and make sure that you're always going to solve their future pain points. NOEL: How do you see your interaction with your developers or with your users? Are there any pieces of this that change the kinds of experiences that you're trying to provide to users or change the way that you are developing the ideas for them? NEIL: Nothing really changes over time. If there are new methodologies or stuff, yeah we'll start using them. More so, we just look at what are the best practices and we just keep trying to follow them. So, we're not really trying to embed anything when it comes to dealing with product or dealing with engineers or the process. We just try to follow the best practices. NOEL: Best practices in terms of like Lean Product Development and the kinds of marketing things that you've already talked about. NEIL: Correct. Yes. NOEL: What do you think that people should know about marketing their own products? Like what do people get wrong that frustrates you when you see people try and do it? NEIL: What frustrates me when people try to work with developers or create product is they believe they know everything and they just build whatever's based off their gut. You should always, always, always talk to potential customers. People use competing products and get other people's opinions and then go from there. You're not building a product for yourself. You're building it for others. So make sure you talk to people. NOEL: In interviewing users, do you ever find it hard to distinguish what they think they want from what they actually need? NEIL: I think it is very hard. I'm not good at that and I don't know how to do that. But the good product people can eventually end up figuring that out. NOEL: Is that something that you then find out like from quantitative data. NEIL: Both. You look at quantitative and qualitative, both analytics and feedback from surveying and talking to people. NOEL: What I would like to get a little more detail on is that process where you merge your original thoughts with what you're getting from the users. Is there a moment where you get excited by something you hear from users? Is it hard for you to let go of your own ideas? NEIL: No, I don't get excited by anything users say specifically. I look at it for volume and then I believe in just continually iterative testing, and then figuring out how can you improve the numbers from sign up to actually using it, from using it to referring other people, from repeat log ins to improving the LTV. I don't think there's one little trick. It's literally a combination of a ton of stuff that adds up. That's how it works with people. NOEL: Yeah. So, you're talking about this as being a slow process of analyzing data rather than like…we often sort of mythologize this kind of processes. There's this sort of flash and you understand exactly what's going on and you rush the white board. But you're talking about this as being almost a completely different kind of process, an accumulation of trends over time. Does that make sense? NEIL: It does. But yes we're looking for a lot of iteration, looking for trends, patterns, data and then we just keep tweaking based off of everything that we learned. NOEL: Do you still get excited by new products? Do you get excited by new ideas still? NEIL: I do. I think a lot of entrepreneurs do and users of many of these SAS products and apps, too. But I'm not most excited like, "Oh, this is cool!" I'm more so excited when things can change my life. NOEL: As a serial entrepreneur, I feel like some people really enjoy the beginning of a process of creating something and some people really enjoy that end of a process of creating something. Which do you feel like you are better at? NEIL: Like my expertise in simplistic form is: someone gives me something that's good. I drive traffic in customers. I can offer my versions and I can offer my services. NOEL: Cool. Is there anything else you want to say before we wrap this up? NEIL: That's pretty much it. It's good being on here. NOEL: Great. It was great to talk to you. Where can people find more about you and the things that you do online? NEIL: People can find me online at NeilPatel.com and they can always contact me through there as well. NOEL: Okay, great. Thanks for being on the show and I'll see you online. Tech Done Right is a production of Table XI and is hosted by me, Noel Rappin. I'm @NoelRap on Twitter and Table XI is @TableXI. The podcast is edited by Mandy Moore. You can reach her on Twitter at @TheRubyRep. Tech Done Right can be found at TechDoneRight.io or downloaded wherever you get your podcasts. You can send us feedback or ideas on Twitter at @tech_done_right. Table XI is a UX design and software development company in Chicago with a 15-year history of building websites, mobile applications and custom digital experiences for everyone from startups to storied brands. Find us at TableXI.com where you can learn more about working with us or working for us. We'll be back in a couple of weeks with the next episode of Tech Done Right.