Wes Winham joins us to share his journey to building Woven, a powerful hiring assessment product. He explains how his own painful hiring experience led to the creation of Woven and describes his team's experience as they grew the product and company.
Wes reflects on lessons learned and the discipline it took to stick to a no-code approach to building the product. His non-traditional approach to growing a startup, hiring, and working with investors give Wes a unique perspective to share.
You can find more information about this podcast at sep.com/podcast and subscribe wherever you get your podcasts. Thanks for listening!
Zac Darnell: Welcome to Behind The Product, a podcast by SEP, where we believe it takes more than a great idea to make a great product. We've been around for over 30 years building software that matters more. And we've set out to explore the people, practices, and philosophies to try and capture what's behind great software products. Join us on this journey of conversation with the folks that bring ideas to life. Hey, everybody. Welcome to the show. As always, I'm your host Zac Darnell. Today, I am joined by Raman Ohri. Raman, How are you?
Raman Ohri: I am good, highly refreshed after a couple of weeks off for the holidays here.
Zac Darnell: It was nice. Honestly, I went a little stir-crazy. The last few days, I think my wife and kids were excited to get back into our normal routine, whatever that looks like right now. Raman, what do you do with SEP?
Raman Ohri: Currently, I'm the president and CEO of SEP. Started there fresh out of school as a software engineer and then just did all the jobs from there to here. One that was really relevant for our conversation today was being heavily involved in recruiting and leading recruiting for a very long time.
Zac Darnell: It was interesting to hear your experience with Wes specifically and with the product and the problems that I know that you've since over the last few years stepped out of leading that effort. But I'm sure for many, many years, we're able to provide a lot of good feedback for Wes as he was developing this Woven product. I thought it was really interesting. One of the first things we talked about, we did do a little bit of level setting on what Woven is. I'll let Wes speak for himself related to the company. One of the first things we talked about was the fact that we're still in the midst even though it's January 2021. We're still in the midst of this pandemic. Just because we're in the New Year, that hasn't changed. And the last nine months has been largely disruptive for a lot of different companies and, well, the people within those companies more specifically. I thought it was interesting, Wes's take on this that they were a remote first company to begin with. From an operational perspective, it didn't really change much for them. But from a people and trust perspective, that was the big, negative effect because they would get together on a regular basis. I loved his hiring strategy. What did you think about that part, especially as it relates to SEP?
Raman Ohri: There was some good wisdom there, and I think a good reminder, no interesting topic is one dimensional. All remote is great, all in- person is great, is the only way. And so remote, as Wes talked about it, remote is not strictly only ever, always remote. They had other things built in and then COVID has messed with that and there are consequences and not taking different parts of your system for granted was a key takeaway there.
Zac Darnell: I thought that part was really cool and ended that little segment with this idea of hiring is really the first step to onboarding. I'd never really thought about it that way. That was a really interesting takeaway from that conversation. And then we transitioned into this... something he's very passionate about with the way that he built and grew Woven's product with these no- code tools and these Wizard of Oz MVPs to validate ideas as quickly as possible. And obviously, the no- code movement has been talked about for a few years now and I'm not an expert in this space. But the thing that I thought was interesting was that he has a cost benefit relationship with no- code. It was really, really hard for his teams to not want to build the full solution and then show it off. You made a great point that that's still hard even though you know it's the right decision. Why do you think that's so hard for people?
Raman Ohri: I think there's a bunch of reasons and they probably all live in the realm of psychology. Most SaaS businesses are started by some technical people and code is what we're good at. So it's natural to get in there and the pride... You build a no- code thing, it may look okay, but you know how shaky it is and that doesn't feel good. Nobody wants to build something that's not of the top level of quality that they could. I thought he had some great insights there on things he might have done different in retrospect and how to do that effectively. And it led into that bigger topic. I'm going to steal your spot for a minute.
Zac Darnell: Do it. Yeah.
Raman Ohri: One of the bigger topic of how they approach the startup, they're the prototypical framework that you read about in a lean startup and now tons of books and media. And then there's the reality of how people actually dive into those. And one, we've just talked about building too much code, but then the way they think about hiring and growing and customer interviews. I thought there were a lot of interesting insights there from him about ways that they were very disciplined and how not easy that was.
Zac Darnell: No, that's a really good point. He went against how he defined the" standard model" in a lot of different ways. It wasn't just the no- code movement. It was really the philosophy with how he built Woven and grew it. That's a really, really good point. I guess we will let Wes speak for himself. Let's get into the show. Welcome to Behind The Product We are joined by Wes Winham of Woven. Wes, how are you doing today?
Wes Winham: I'm doing great. I just got off of 15 days of doing nothing work- related, so I'm pretty excited to be back.
Zac Darnell: Oh, that's awesome. Did you get a little stir- crazy over those 15 days, or were you relaxed?
Wes Winham: I got some reading in, I got a new baby. She's four months old and I got to see my parents and my wife's parents. I was pretty relaxed. I ate way too much food. It was pretty great.
Zac Darnell: That's awesome. Well, congratulations on the new baby. Is that your first?
Wes Winham: It's my first. I tell people I have the best baby. I got super lucky. She sleeps, she's happy. I hear that sometimes the second one is different. So I'm just going to appreciate this one while I got it.
Zac Darnell: I'm sure it's different for everybody, but that was my journey. I have two boys, a little bit older. But yeah, our second one, very different baby than our first. Hopefully, you get just get two sleepy happy babies.
Wes Winham: That's the dream.
Zac Darnell: And Raman, thank you for joining us for being our guest host today. How are you doing?
Raman Ohri: I'm good. And by the way, I can confirm I have three sons, all radically different, almost nothing alike, the three of them, other than loving Legos.
Wes Winham: I will have no expectations.
Zac Darnell: All right. Wes, just a little context setting, tell us a little bit about you, tell us a little bit about Woven.
Wes Winham: I'm Wes. I'm originally from Oklahoma. I'm a software engineer. I fell in love with startups in college, founded one. That one totally failed, but got me involved in another startup I did for 10 years. And then founded Woven about three years ago. Woven is a technical assessment platform, as I think what I'm supposed to say. But we do do things a little bit differently. I think most technical assessments suck. I think balancing a binary tree is a ridiculous way to evaluate a senior engineer. I think engineering is more about problem- solving, working with minimal context. So our assessments are like real work. They're real work scored by real engineers so that you can find better engineers that are a better fit and do that with less engineering time.
Zac Darnell: Oh, man, I don't think I could agree more as far as a lot of the conventional ways that people assess engineers aren't great. I love hearing that and we're actually a customer of Woven at SEP. I know Raman is a big supporter. Raman, what was your early experience with Woven like?
Raman Ohri: Well, where do we begin? I spent too much time on it. But I had met Wes a very long time ago, ironically tried to hire him, interviewing him out of college. I don't think we got to the technical assessment... No, we did. We did. But I don't think I was there for that part. I don't know. If you have any horrible memories from that, it is my fault. But anyway, we'll move on. I've been not very interested in trying any services or products related to recruiting things because I had such a disdain for how the industry at large approaches this stuff. And Wes wanted to talk, which was pre- product even. I think you were doing deep research on like what are real problems that people doing this are having? Even from there, I thought like, "Okay, this is the one time that I would actually consider it because I don't know Wes well," but I knew what caliber of engineer you were coming out of school and I knew the circles you had played in and I knew that you had tried to build up engine, not say try, but you succeeded in building up engineering teams.
Wes Winham: A little bit of failure too, crosstalk.
Raman Ohri: Yeah, learning all the hard lessons we learned like, "Okay, this is the one shot I'm going to give to a service outside because the situation is going to be any better than this." And I also knew Wes's as co-founders reasonably well too. Early days with Woven were awesome, still awesome, although I'm not directly involved. Everything I hear is good, both from our candidates and from our folks. They've come to rely on the reports. So to tee it up, and then Wes correct me, we will interview a candidate, just some initial screening, and if we think they look interesting, then we'll route them to Woven. And Woven will give them a tailored assessment that's been trained on the characteristics we look for. We get back a report that provides some very specific feedback, did this well, didn't do this as well as other candidates and a score. And our folks have come to depend on that, interviewers going into the final interview are like, "Where's the assessment? I need to see that, or I saw this in their assessment. I want to dive into that when we have them in for the full interview," which I think is a pretty strong, positive signal.
Wes Winham: I think the fact that you dive in on things you learned in assessment, I think that's what the best interviews do. They're not memoryless. They're Bayesian, they update based on what I heard a little bit, I want to learn a little bit more about this. That makes them smarter. I think there's this idea that we need to be completely memoryless and unbiased, but it makes decision-making worse. I think there are ways to fight bias, but forgetting things is maybe not the best one usually.
Zac Darnell: Well, being somebody that has a terrible memory, I love that concept. I need as much support as possible. Today is... We're recording this. It's January 5th, 2021. We've obviously been in the midst of this pandemic for the last nine months. I'm curious about Woven's experience, your experience leading a startup through this period of time. How have you guys adjusted? How have you and your teams adjusted to not being physically together? Is that been disruptive for you guys the last few months?
Wes Winham: We're like an AB test in this thing because we were distributed from the start. Founded the company, were going to be remote first. But we relied a lot on getting together periodically to build trust and do some community building things. So our operations, not affected at all. Even though I believed that in- person part was important, I think I underestimated how important it is. I've seen interpersonal situations, where just a little bit more trust would have saved so much gnashing of teeth and questioning and motive doubting. That didn't happen in our first 18 months. We got together a lot. And then this hits, we stopped doing those rituals. It is harder to remember that we're people that are trying our best and are flawed. I think getting together in person is just so currently irreplaceable for that. We just bought an Oculus Quest too for a bunch of our folks. So we're going to try some VR stuff to replace it, but I don't think it's going to be quite there yet. I think that trust is really what I rooted combined with the general like everybody's got more stress, we all got our cortisol levels way up to here, we're going to in our social connection. I think just generally, we're all a little bit less resilient to stress. I think we're a little bit more emotionally reactive, a little bit less trusting. And man, that sucks. I don't know way around it. We're doing as many remote Zoom happy hours as we can get away with. I don't know if they're really moving the needle. But that trust and connection it's less.
Zac Darnell: It's interesting to hear the conversation has been remote work forever and this full forever changed the way that we work and all these different soundbites. Do you think that we're recognizing the importance of not necessarily being in the office together every day, but having those regular rituals? Do you think that'll let you increase or change the way that maybe Woven is structured physically when we can be back in the office together?
Wes Winham: From the beginning, if you read automatic, like the OG remote distributed team with hundreds of engineers, they got together for weeks. They had this cascading series of get together. So they were about it from the beginning. I think that gets lost sometimes in the messaging. We actually, at least up until now, we'll see if it changes. I've only hired people that have a direct flight to Indianapolis. So there are 80 million Americans and some Canadians in there that live in metros have a direct flights to Indianapolis. So we can get together pretty easily, and that's been part of the strategy and it was, "We're going to get together recorder. It's a direct flight. It's not a big deal." And then COVID blew all that up. I think having those rituals is so important.
Zac Darnell: I've never heard that hiring strategy before. That is awesome. I'm just curious, that happened organically, or did you make a deliberate decision to start with like, "Nope, we're going to look for direct flights to Indy"?
Wes Winham: I was in the airport and a connecting flight that got delayed. And that was when I was just like, "Oh my gosh, flying is not bad, but connecting flights are the worst." I'm from Oklahoma, Indianapolis, there is no direct flight. It is the worst. Sometimes I fly to Denver and it's like, "Oh, that was no problem. I'm already here." One of the learnings from happiness research is that people way underestimate how much commutes harm them, like chronic stress. They do these studies where you text someone randomly throughout the day and you say like, "What are you doing? How happy you are?" Consistently commuting is the lowest in people's day. People will accept jobs that are 45 minutes away, an hour away, even though it makes them measurably less happy and they leave those jobs sooner. I think as humans, we're pretty bad at estimating how much that chronic annoyance impacts us. I think direct flights are just one way of taking a small step towards like, "Okay, I think that actually matters more than you might think it does." So let's build that into our strategy for now.
Zac Darnell: Oh, that's so cool. Moving from like Woven's people to maybe Woven's product or business, do you think that some of these circumstances has changed your maybe growth projections, either positively or negatively?
Wes Winham: Yeah, definitely. We had two months in a row where we had zero new customers. And for a startup where growth is everything, that was pretty scary. March and April everyone was holding their breath on hiring. So that was pretty scary. What's going to happen is it's going to come back. It did. We're back on our growth trend, but we did lose a couple of months. What's been interesting for us is if you were to talk to me in 2017 like when I was going out and interviewing Raman with a tape recorder on a table on Starbucks and just trying to learn as much as I can, I really wanted to build a thing for remote hiring, but it just wasn't there. There were like maybe 200 companies that had at least 10 engineers that were distributed. It was just really weird in 2017. One of the things about hiring is I think there's two paths. There is, "I don't have anybody applying at all. I'm in a small city. I'm not good at marketing what I do or maybe it's actually not exciting. I can't pay market rates." In that case, you just got to get some bodies. You're not trying to hire majorly players. You can hire out of the minor leagues. You just got to find them. So that's one problem. The other problem is like, "Oh, man, I got a lot of people, but they all look the same, they're all resumes. I can talk to them and they're good at talking." But we all know being good at talking is only loosely correlated with being a really productive engineer. I have worked with 10X engineers, so I know they exist. So how do you find them? Two different problems. If you are remote, you don't have the first problem. That does not exist for remote companies. Every remote company gets the same applications that you would get if you were like Google relative to your size. You just get so many great candidates. If everyone was remote, I would remove this first problem and then that second problem is about selection and finding the right people, which is what I was super jazzed about. I'm not a sourcer. I'm not going to go knock on LinkedIn doors. So remote eliminates that first problem. Now, everyone has a selection problem. And man, COVID accelerated remote so much. I've seen statistics like 60% of engineering teams that previously did some work from home are now going to open up to hiring least outside of their cities, if not full remote. I think it's just accelerating the trends. I think a lot of companies that were previously heavily leaning co-located are now, "Hybrid is not so bad. I could probably hire someone from that... We're in Indianapolis, Cincinnati is two hours away. Maybe I can hire someone from Cincinnati and they can come in once a week and drive." People are thinking about that now, which has changed what we're able to do. So we're able to go all in on remote companies, what's the best thing for remote companies versus maybe that would have been three years down the road. It's pretty exciting for me.
Raman Ohri: Do you find that for a company that went from strictly local to now incorporating remote, they may find themselves in a position where like, "I don't know how to do this well. I knew what to do if I could get them to come in the office and meet these four people." Does this open more doors, give you almost more credibility, that's not exactly the right word?
Wes Winham: I think so. I think right now, there's this transition period where everyone's remote, we have a lot of grace for everyone because, okay, you have to be remote, you're not necessarily good at this. But there's going to be this transition period where if you're remote, you are being compared to other companies who are remote first and have learned some lessons, although we're all learning lessons right now. I think coming in with some credibility like here's the job boards to use, here's some onboarding templates, here's some rituals that work, here's a way to think about getting together I think that does bring some credibility and we should write more. That's one of my 2021 resolutions is to get more writing out there of stuff that I have great conversations and learn a lot from people who are really good at this and then I just sit on this. Raman, if you don't see me write more blog posts in 2021, you should send me an email.
Raman Ohri: Got you. Will do.
Zac Darnell: I'm actually curious, SEP has been around for... coming up on 33 years? And we've been in the office together for that length of time and this was the first time that we had ever had to disperse and kind of go fully remote. Wes, as you were talking about some of the things that you experienced with your teams early on, I didn't see a lot of that at first, but we've also hired some new people through this period that have never been with us in the office. I can see how drastic change and your cultural shift at least for us could dramatically impact the way that people interact with each other in this trust building and just getting to know each other. There really is no replacement for it. It impacts everything from the way that you hire to the way that you build teams, to the way that you groom the next generation, to a number of things. Do you think that these shifts in the way that a lot of companies, like you said upwards of 60%, could be remote forever will influence some of Woven's product roadmaps or the things that you'll start to add into the suite of offerings you guys have?
Wes Winham: I hope so. That's the vision. Hiring is the first start of having a great productive engineer that's integrated in your team. That's the first step. It's not the last step. I was an engineering manager. I didn't have time to have a super cohesive hiring to onboarding flow, but hiring is a first step to onboarding. It's crazy that we throw away all this stuff and then we stop or at least I did throw all this stuff and then stop onboarding. Why can't part of hiring be you're learning some of the things you need for onboarding? Why can't some of the onboarding training be pulled before hiring? There's just so much opportunity there, where an engineer designing a process would not design it this way. But we've got recruiting, we've got not enough times is all our second job. I think there's a lot of opportunity to add some engineering to this really important people process.
Zac Darnell: That's very good advice and very good point.
Raman Ohri: I don't know if you want to go here without giving away the product roadmap is that the arc that you see Woven going towards, you started with being very good at assessment. I know you've explored matchmaking. These people come into your system and you learn some things about them and then companies come into your system and you learn some things about them. You have some opportunity there, but then also the long life cycle of a single person into a company and becoming fully integrated, invested and productive, is that part of where Woven is going?
Wes Winham: I'm a product person. So I get too big for my britches sometimes. I'm curious, so we can do a little bit of mini customer discovery. When you have leveling discussions, does this person come in as an SE2 or when do they get promoted? Is that all based on peer reports? Do you have any data you bring to that system?
Raman Ohri: There's data. It's not very good data. The silliest, stupidest proxy that we all use is years of experience, and it's a crappy, crappy proxy. It's not that it has no value, but it certainly doesn't tell the whole story. That is the most common piece. But beyond that, we're looking for demonstrated capability in a number of areas. So we think to be good at this job, this level, this role, you need to be good at these things. We know it's completely flawed system, but it's something. It's a scaffolding to start with. Can we get those experiences and then can they take advantage of those? And when it's obvious like, "Yes, they can show that they can do all those things, they'll be good at this," great, then let's make them that. That's how that goes for us.
Wes Winham: That's what I hear. I think you're doing it well and that you have a matrix, you have definitions. I think a lot of other companies are like just the years of experience, which does have some predictive power, but we all know that's a bell curve and it's the best we got. A thing that we're exploring is how might we aid leveling as part of hiring and promotion? How can we bring some data? Imagine a world where you have a matrix of things that... the capabilities that you need an engineer. And then you've got a mix of stories of them doing this. And then a little bit of assessment, where you can see how well do they do this in a standardized way? It's data, it's not the decision, but some way to bring some data to what's a really important fuzzy conversation. I think especially I hear stories of folks that they don't actually level people until they're six months into the job. And sometimes that makes it really hard to compete for what would be a staff or principal engineer? Do they want to take that risk on that place? Don't quote me on this, but that's where we're getting some energy on very assessment- related problem that is on that life cycle of having a great team member that's growing and getting better.
Raman Ohri: We can do a whole podcast or five on just that topic. If you ever want to talk more, I think I have been personally involved in at least a significant majority of the mistakes you can make in doing this.
Wes Winham: I will take you up on that.
Zac Darnell: I will look forward to hearing some of that conversation because I love to learn more about this. I've learned a lot in my last couple of years here at SEP and the way that we do this. I want to dive into, Wes, another subject that you are seemingly particularly passionate about, this idea of Wizard of Oz MVPs and no-code, quickly validating ideas. I think it's safe to say that we all know that it is a good product development practice to validate ideas or invalidate them as quickly as possible with the lowest amount of spend. I don't think there's much argument to that. I don't know a ton about no-code, a quick Google search told me a little bit. Tell me a little bit about the no-code movement from your perspective.
Wes Winham: I can tell you what I think it is and then how it's affected how we've done our business. No-code it's like serverless... Yeah, there's a server somewhere. No-code, there's code somewhere. But it's the label that means building stuff really fast without writing a lot of code often in a visual manner, often in a way that a non-technical or... They're technical. They can do technical things. Using a fork is technical. It's a gradient. They're less technical. They're not engineers. They can adapt systems and sometimes even build them. You can go so, so fast compared to even great engineer in their favorite stack. It's crazy how fast you can iterate. So that's the tool, faster iteration, faster time to value. What's this enabled for us, so backing up a little bit, I was head of engineering at a startup, did a bunch of hiring, thought I was awesome at it, had my first failure. Oh, not awesome. And so for me, I had a small team, one person that is a lot slower really made a difference. There are some places where you want someone who's a good teammate and if they're good teammate, that's okay. There are some places where if you're three times slower than the average engineer, let alone 10 times slower than the really, really top 10% engineer at the same level of quality, it's just really tough to have that seat be taken up. I hired a great person that was in a seat like that. It sucked big hole in my roadmap. I had to let him go because of the type of team I needed and I didn't ever want to do it again. So talked to a bunch of grizzled engineering managers of what actually works for the IO psych literature, what does science say predicts hiring, the Venn diagram overlap is if you're going to hire dancers, you should watch them dance. So like, "Duh," okay. Yeah, doing some engineering, predicts engineering. Cool. I think I should have known. I started doing more of that. And the closer it looks like the engineering they're doing, the more predictive it is. For me, that was like a project where you do some work in a web framework with vague instructions, which is what engineering is. So fixed my mis-hiring problem. Then I'm going to tell you this, this is the story of that startup. It's true, not the one that is cleaned up. True. I was like, "Work simulations, take home tests. This is the way to stop mis-hiring because mis-hiring sucks." And so sold my startup, started this new thing. And then I spent six months doing customer discovery because I was going to solve mis-hiring. We went and we built work simulations like take-home tests and tested things. If I would've done it the way that 20-year-old me would have just built first, I would have built the best thing to stop mis-hiring in the world. Nobody cares about mis-hiring. Nobody. I would've built something for absolutely nobody. Nobody wants to spend four hours people care about saving engineering time, increasing quality, but nobody has a mis-hiring problem. But we built a no-code solution. Instead of going and building something in rails for a year to build this great product to stop mis-hiring we built something really quickly in Google Sheets, which is the best no-code solution, Google Docs, Airtable, which is I think they're officially part of the no-code movement. Airtable it's like MS Access back in the day, but in the cloud and very, very good. It's a database that you can edit as just someone who could use Google Sheets. So we actually hooked that into our application. We were using Zapier everywhere. So things that would take a couple of days to build and build well, I could do in 15 minutes in Zapier to integrate systems. We used that to build a system that we ultimately threw most of it away. And if we hadn't had no-code, we would have been six to nine months behind, and we might even have died because we might have just clutched onto all this great code we wrote. A thing about no-code, you get there faster. And it's a lot easier to throw away that Zap that you wrote than that class that's really well-tested and like, "Oh, man, I built this monitoring for it." I think our startup might not exist if we didn't have this kind of no-code instinct and no-code tools.
Raman Ohri: I think it's very common wisdom in the startup world, any product development world. Let's not build too much, let's spend more time talking to customers, let's really make sure we understand the problem. And so few people seem to be able to do it. Even people who aren't especially technical will feel like I have to have this working strong piece of code, let alone... I think your founding team is all very strong engineers. How did you have the willpower to not go build when it seems like everybody falls in this trap?
Wes Winham: It was so hard. We were the perfect team to be aligned philosophically. We were all engineers who had built shit that nobody used. That's the main thing. You do that a couple times and you start to be like, "Yeah, maybe I don't want to do that again. I don't want to pour my soul into this thing that doesn't get used." So we all had that experience. We're like, "We're not going to do that." We were like lean startup folks. We had a group called Desperately Seeking Validation, where we just did quick validation. We were primed for this. And it was still so, so hard because you have this pride as an engineer. We shipped PDFs for the first 13 months of our company. That was our product, shipping PDFs. And that hurt so much. We were taking screenshots of stuff and turning them into PDFs for so long. And every time we did it, it just hurts your soul. I love no-code. I'm going to talk a little bit about what's bad about it and the reason I think people fall out of it. These systems, they're brittle. You have to use real engineering and it's harder to go from prototype to well-engineered thing. There's this big gray area where you're under a lot of pain as an engineer, for my co-founders who they were along this decision with me to build it this way, but they had to take the brunt. I was out trying to learn how to sell, talking to customers and prospects. They were in there dealing with these brittle systems that they didn't feel good about. I think it takes a morale toll to be an engineer and know that you could build this thing and you have this itch. That's what makes us good engineers is you have that itch to like, "I'm lazy. I know I could like..." There's that XKCD, pass me the salt. What's taking so long? I'm building a system to pass you arbitrary condiments. That's the engineering thing. And to go against that instinct and build this crummy thing that you're showing the customers, it just feels really bad. There are months where we just had to have hard conversations where we knew we all felt it's time to build, but we just had to have that discipline of like, "Yeah, but is this the thing that's going to kill our business because we can't build this?" And we kept having to say, "No, it's not the thing that'll kill our business. If we don't build this, it's this other thing. So let's go test faster." It's so hard, Raman.
Raman Ohri: The empathy part of me wants to go back in time and being on the receiving end of those PDFs and screenshots, as we were executing our interview process. It didn't even cross my mind that this wasn't... I knew it wasn't really automated in any significant way, but I could have cared... All I cared about was, "Well, tell me about this candidate because I need to know whether I should take the next step with him or not." That's it. That's all I cared about and the value I was getting out of it. I wish I could go back in time and tell your team like, "No, no, no, no, you're making my day. Every day, you're making my day. This is making my world better." This is probably what they needed to hear.
Wes Winham: I was the product manager for part of it. And that was, I think, when I was doing well, I would seek out those sort of stories and say like, "No, guys. I know it feels bad, but look at this candidate got hired." I think that's what good product management engineering leadership do. But yeah, it was hard to look at those PDFs every day.
Zac Darnell: A minute ago, you mentioned that there are maybe some downsides outside of maybe some morale and maybe some emotional response to using no-code. Are there other kind of negatives to taking that approach? If you could go back, would you do something differently?
Wes Winham: No, I wouldn't do anything differently because I like where I am. But I think getting earlier standardization around how you're going to use no-code and where you're going to use it and where you're not and what's the point where you promote something to production. I think we could've spent a half day workshop aligning on our rules of engagement for when we're going to do this and not that would have saved a lot of painful discussions about like, "Ah, is this the time?" It feels like it should be. And then also for Zaps, for instance. We learned that Zaps by default fail silently. And that sucks whenever your product just fail silently and your customer is like, "Hey, where's that thing that I've been waiting on that is very important to my business." And you're like, "I don't know, it failed silently four days ago and we didn't know about it." There's just like this kind of hygiene around your no-code tools. I think there might be this perception that like, "I'll just use no-code and everything will work." I think we could have applied an engineering mindset earlier and built less brittle no-code systems. We've since evolved some of those practices. We always add logging for Zapier alerts and failure to Slack and some things like that that we just didn't have earlier. I think that would have smoothed out some of the rough points.
Zac Darnell: That's a good point. I would imagine that no matter what tool set, I don't know if that's a good way to describe that, some of those lessons you would learn along the way, I feel like that's a not terribly uncommon story. Just before we actually started recording, we talked about your opinion or journey through building this company and the non-standard way or building against the "standard model." I'd love to dive into that. I think it's maybe a good time to ask this question. What do you view the standard model to be and why do you think you deviated from that or how did you deviate from that?
Wes Winham: The standard model as I would describe it for a venture-backed company that has a crazy dream, wants to change the world is you go work at Stripe, some great engineering organization that has a big name and a good reputation, then you take a couple of your friends from that company, you find a problem that you encountered... This is like a SaaS story. That's the world I know best, software as a service. And then you go spend a year building something. There's a lot of talk about lean startup. I don't see a lot of it. I still see so many startups. It's like, "We're launching at 18 months." That's still the norm. They go build and then they sign up 10 of their friends that work at other big name companies so they can put those logos on your deck. They don't charge them anything. All they really need is a logo. And then they go pitch a bunch of seed investors and they say, "Look at these three names from Stripe." I'm not picking on Stripe, actually. I love Stripe. "Look at these logos on these pilots we have. Do you want in because the next guy is going to write us a check if you don't?" That's the standard model and it works clearly. I think it works for getting investment. The challenge is, is so easy to build the wrong thing for a year. If we would have followed their model, we absolutely would have built the wrong thing. Maybe we could raise enough money to pivot, maybe we could've gotten through that hard time. But instead, we went out. I had 30 customer discovery conversations. I recorded them. I use those to convince my co-founder that I was not crazy that, "Hey, this is a real thing." Went out and pre-sold a deal with a contract. I said, "If I build this, will you buy it? Please sign here," I emailed a friend.
Zac Darnell: Letter of intent, basically?
Wes Winham: It was actually a contract. It was a real contract.
Zac Darnell: Oh, wow. Awesome.
Wes Winham: I just emailed someone, was like, "Hey, do you have a contract that I could use from another CEO?" And he's like, "Yeah, try this one." I was like, "Oh, find and replace. That is good enough." And use that to say, "Hey, this is real. We're going to raise money right now. It's like we're going to go spend the year together figuring this out and then we're going to go out and raise money." We charged from day one. I remember the first time I asked for money, it was someone I had met at a meetup that was hiring their first engineer and I asked for $3,500. I was just terrified. That felt like so much money. And he was like, "Oh, wow, that's okay. Cool. Yeah, absolutely." And I'm like, "Oh, oh, okay. I guess." Now, we charge 10 times that and people don't bat an eye. But we charged from the beginning because I needed that. I needed to know that what we're doing is valuable. I needed to justify to myself it was worth it. Pushed us to do more in the product. We were signing annual contracts from the beginning, which learning how to do sales from the beginning, iterating with real customers who were paying us from the beginning, and trying to drive revenue up so that we knew we had a real business, not just a bunch of logos for people who are willing to entertain us, although there's definitely a lot of that, folks like Raman that were willing to take a chance on us. We didn't know what were doing clearly, but we were very excited about it and we're going to work hard. I think willingness for folks like that to take a chance on us is the only way that works. But we actually charged and gained revenue and built the business that way.
Zac Darnell: How did that change maybe the conversations with initial investors?
Wes Winham: There's this really weird thing with just human psychology that we value potential much more than realize potential. This happens in draft picks in the NBA and the NFL, where draft picks are worth more than an above average second year player, which doesn't make any sense. Like you think you're going to do better than average for picking randomly and the same thing's true with startups. If you have a little bit of revenue, there are some investors that will discount you relative to that other company who has no revenue in the potential. I know why those Stripe guys raged with a slideshow. Because if you have zero revenue and infinite potential, the conversation's different. It's about the idea, it's about the potential. And that, there's a lot of advantage to that. That's what you want to be talking about. My job was to... I had to convince myself it was real with the revenue and then I had to almost discount the revenue and the trendline that I was so proud of and talk about the idea, like that's the thing, the vision. It's a weird little dance between what really builds a business and what you need to do to convince folks of the future potential, which I wasn't lying, I believe in this potential, but I had to very much change the frame of the conversation.
Zac Darnell: Yeah, you're right. Those pre-revenue conversations are, I'm selling the world, I am going to change the world versus here's a little bit of reality that validates that this is a real thing. I know it's going to be more than this. But don't focus so much on it. That's really interesting.
Wes Winham: Yeah. It's like you said, an anchor. You anchor them closer to zero than infinity at that point.
Raman Ohri: Wes, I don't know if you remember this. You and I met at an awesome Jamaican restaurant near SEP one day, well after you had Woven up and off the ground. You shared some stuff about things you were doing. I think at the time, I was evaluating a different startup for various reasons. That's not my world. I work in more professional services arena. I was just trying to pick your brain about some things. One of the things you said in that meeting, sticking on this, doing things a different way, just blew my mind, has stuck with me ever since, and now you might tell me I'm remembering wrong, but you talked about almost having a mental model for what investors expected in terms of revenue growth and opportunity growth, whether you express it as ARR or some other method. And almost knowing that at this milestone, the investors, either my current or potential investors, will expect to see a certain inflection here and here and here and it needs to look like this. And so from that, I can reverse engineer back that now I need to hire more marketing, or I need to hire more customer success. I had never had anybody approach it that way. I've always seen it from the other side, the "Oh, crap, we can't answer the phone fast enough. I got to hire more salespeople." Can you talk more about that? How did you arrive at that idea? How well has that worked?
Wes Winham: I definitely stole this idea. I think exact target here in Indianapolis, that's how they built their business is they got in the spreadsheet and they're like, "We need to get to this number. What do we need to do six months before that number to make possible to do 12 months before that?" All right. Listen, induction this. If you're on the venture capital game, their expectations, you are... It's a beauty contest. Are you the better investment relative to other investment? There is no absolute best investment. There's only better than other options for this investor. There's a lot of psychology to like who do they like hanging out with and what gives them status? You can't control that as much. That changes, the changes of the macro economy, the changes with your ARR. So just knowing those benchmarks is really helpful. There's a survey called... It used to be called Pacific Crest SaaS Benchmark. I think it's got a different name. But you can actually go and look up for private companies at this scale. What is top quartile revenue growth? What's the median? What is net dollar retention? Which is like I have $1 worth customers. I look at those same customers a year later, are they worth $1.20? Are they worth 80 cents? You can get some of those core metrics and then you can work backwards. It's like, "Okay, here's our target. Here's where we need to be in 12 months. I know that I need to hire a sales development rep to do cold calling or whatever, a marketer to learn how to create an ad campaign. I know that it takes three months to ramp them up to productivity. And then there's another three months ramp." So if I want to hit this input and I have a two- month sales cycle, so if I get a lead, it takes me two months, you can just do the math working backwards, and you can say, "If I don't spend money now, I'm going to miss my number in nine months. And we're going to drop down a rung in quality of companies relative to other investments, and we're not going to get that venture capital money. It's going to go somewhere else. And we're not going to get to make the impact on the world that that kind of money makes possible." So it's a spreadsheet. The spreadsheet is always wrong. You're always making ridiculous assumptions. Sometimes you're optimistic, sometimes you're just clueless. But if you don't make that, you are pretty much guaranteed to be wrong. It makes you a little bit less wrong.
Raman Ohri: Yeah, that's fascinating and leading a completely different kind of business. Even a model that is frequently wrong, it's a refreshing alternative to, "Well, I'm going to trust my intuition, or I'm going to do what I did last time when I think about growing this or expanding or adding this capability." Any business leader stands up and says it confidently in the email or the all- hands meeting. But the reality is you don't know for sure it's the right time. You don't know if you're early or late, or if this is the right person. Like I said, that story really stuck with me. It's an alternative way to think about those key milestone moments, when to make different kinds of investments.
Wes Winham: You still have to stand up and you still have to... It's like you're schizophrenic. This has to be very critical engineering mindset. Is this going to work? Let's stress test it. And you have to have this other mindset, which is like, "I believe in this thing. If we are all critical of it, it will not happen." We need this positive belief to go out and take the risks and make it happen. Otherwise, it's going to be a self-fulfilling, negative prophecy. I think it's tough wearing those two hats and let's go build the spreadsheet where I learned that, "Oh, I don't think my SDRS can work 120 hours a week. Probably that assumption is wrong. Probably need to change something here and then go and put on the hat of like, "This is why we're doing this. We're going to hit this number. We're going to go, make it happen, create this reality." It's tough to bounce back and forth with those hats.
Zac Darnell: Oh, man, I bet. And such good wisdom from two awesome leaders. Wes, thank you so much for joining us. I appreciate you.
Wes Winham: Great to be here. Thanks, Zac. Thanks, Raman.
Zac Darnell: I'm Zac Darnell. And this is Behind The Product, an original podcast by SEP. You can find more about us at sep.com/podcast and subscribe wherever you get your shows. Thank you so much for listening. See you next time.