106. Growing a Self-Funded Company

Lewis: Yeah. Right back at the beginning of our recent project, we were thinking about different technologies for a new feature that we wanted to add to our application and it was going to involve a lot of data. There was definitely some discussion, would the monolithic architecture still fit for us for that pattern? And I think over time, as we've kind of gone through the project, it was a great choice to start with that pattern and to continue using that monolith application that we have. We already had it set up so we could spend a lot less time worrying about what the technology would or wouldn't do. It was tried and tested for us, so to speak. We could really focus then on building value for our users and addressing that risk rather than thinking about the technology. I'm always safe in the knowledge that if we did run into any problems or performance or scalability concerns, we'd always have options to iterate and make improvements in that area in the future.

Greg: Maybe Alli or Lewis. Could you tell us what BiggerPockets is and what you guys do?

Alli: BiggerPockets was founded about 16 years ago to be the antithesis of the real estate guru. There are plenty of people out there who will say, "I'll teach you everything I know about real estate for $50,000." Our founder, Josh Dorkin founded us to be really the antithesis of that. People like real estate and they like to talk about it and that knowledge and information should be free. And so we were founded on those tenants to be 1) a place where people can learn about real estate and 2) a place where people are safe and can talk about real estate without being spammed. Without people saying, "I'll take 10,000 of your dollars and teach everything I know." We create forums. We're a community of over, I think, close to two million people now where people can engage in conversation and ask questions.

Alli: And in addition to that, we produce - you name the medium of content and we produce it. We also have podcasts, books, different types of videos, webinars, blog articles, guides, tons and tons of content to help people invest in real estate smartly. And then even now Lewis and I get to work on this tools project, more geared membership that helps people analyze and find and think through investments that they might make and decide if that's worth their time. That's where we, Lewis and I, spend a lot of time and thought.

Greg: That's awesome. Sort of like democratization of real estate knowledge and investing knowledge and embedding that into tools so folks that maybe historically were a class of folks that have not been able to invest in that sort of investment now have an opportunity to learn about it, dip their toe in it, try it and maybe be successful with it.

Alli: Yeah, definitely. And we certainly, our mission is to help people invest in real estate wisely, not necessarily to make their choices for them, but to help them make informed choices.

Greg: How do you guys operate? What's your team structure look like?

Lewis: About half of our overall team is our product and engineering team. Product and engineering is then further split into three sub-teams and where we're each responsible for different parts of our application, focused on different areas of our product. As Alli said earlier, yeah, we were focused more on the pro product. We're really working in these cross functional teams with a product manager, tech lead, designer, all working really closely together and collaboratively to discover what problems our users are facing and then coming up with solutions to those problems together and as a team shipping solutions to them.

Greg: That echoes some of the early experience I had when I started at Heroku - every team had a designer and a product manager embedded in it. Even something as simple as the CLI team, had a designer thinking about user experience of the Heroku command line and what it would be like to be a developer using it. That sort of design led thinking was super important to us. And it's nice to see other companies in other industries and other verticals go ahead and just use that same kind of mindset because I think keeping the customer at the center of what you do is super important.

Lewis: Yeah. I certainly really enjoy that. And it's really nice to all have that shared context and that shared understanding of the problems that users are facing. And then each of us, with our different specialties within the team, coming up with solutions, talking about them and everybody contributing to hopefully produce a solution that's going to really delight our customers. And that's, I find a lot of satisfaction in doing that myself.

Greg: Alli, as a product manager, how do you interact with those teams? Super interesting to me because I've seen product managers work. I know what the title means, but as more of an engineering person who's never really worked with one, how do you interact with the teams and what value do you bring?

Alli: Yeah, so I, as a product manager, get to sit in just the really fun seat of advocating for whoever's not there. Oftentimes when I'm sitting and meeting with Lewis or our product team with a couple of engineers, QA and a designer, I spend a lot of time talking about the user and talking about what we've learned from customer interviews, what people liked in this prototype that we showed them, thinking through what problem are they facing. Hey, I watched screen recordings of people using this tool. Here's what it looked like. Here's where they went. A lot of knowledge sharing and then also trying to build that empathy muscle totally across the team. It's really valuable for us. I'm really thankful to get to work with Lewis and engineers like Lewis, who care about our users, where I can talk about what our users are facing - here's what that problem is, specific quotes, here's what this user said - so that we as a team can talk about how we can build something from the front end, more layman's type of idea of how we can make something better.

Alli: But it's been really fun and valuable to ask, "Hey, Lewis, what do you think about how we can make something be better, work better, move faster?" And then you get a lot of technical ideas that I couldn't come up with on my own that are actually a really wise use of our resources, so to speak. That's one piece. And then the other piece is talking more about the business because it's really great to build products that have a really good experience, but it's even better when that product is valuable in the market. Someone recently told me that as a product person, you also have to advocate for the business because there are a lot of great products out there that fail because they didn't make any money. Making sure that you're in a field that is solving problems that people will pay to be solved in some way. Otherwise, yeah, you have a great UX, but who's paying your salary?

Greg: Yeah, that's great insight. I had one product manager when I asked him the same question a few years ago, he said, "Think of me as the CEO of the product. I'm responsible for talking to customers and figuring out what they need and then making a business plan around how we can solve that and charge for it."

Alli: That is definitely true. Thinking through what can we do for the business, and what can we do for the user? And finding that intersection. And then the third piece of that Venn diagram, if you have one pictured in your mind like I do, is what can we do from a technical perspective? Because the other relationship that I really value and want to preserve is my relationships with the people building our products, the engineers. Of making sure that they are advocated for and we're not biting off more than we can chew and building up a mountain of tech debt that's going to have engineers quit at the end of the month. Because that's every product manager's nightmare.

Greg: Yeah. We all love tech debt. I had to explain tech debt to somebody who was non-technical a few weeks ago. That was an interesting conversation. The title of this is Growing a Self Funded Company. I assume that when BiggerPockets started 16 years ago, it was like GitHub or something like that started on a credit card or some sort of internal investment like that. How does that kind of impact what you guys build and how you think about the product and how you think about your customers?

Alli: Yeah. That's a good question because a big part of what we think about is can we do it, but should we do it? Is this a good use of people's time and money? If you build it, will they come? And so us thinking through and talking to users, figuring out okay, well, what are the problems that our users are facing? We have a big user base, what are they encountering that we can be a part of? How can we help fix this problem? And what is this problem? And so we think a lot about users. What challenges are you facing? What are your expectations when you get to BiggerPockets? How did you find us? Thinking through kind of what the journey is and how specifically for investing in real estate, how does BiggerPockets fit? And how could we make room for ourselves to be more in our users' lives in a healthy way?

Greg: When you do look at that, what do you find that's missing in the landscape? And what problem areas do you attack?

Alli: Specifically for this tool that we've been working on this year called BP Insights, I think in the first customer interview I did at BiggerPockets, probably two years ago, a user said to me that she wants to invest in real estate, but is scared. And she just wishes there were a Kelley Blue Book for real estate. She knows how to negotiate car prices. She knows what it's worth. She can go see a 2009 Honda. I know how to negotiate this. I don't know how to do that for property. You guys could just tell me what it's worth. That's what I want.

Alli: I was not the only person who heard feedback along these lines, which was really nice. One of our VPs and our director of content had also heard feedback along these lines and then thinking along these lines. And so we started talking late 2019 about how do they enter this market data space? How do we provide context and insight into these markets that our users may want to enter? How do we help them understand - if I bought this property and wanted to be a landlord, what could I rent it for? What would happen here? And so helping users gather that context was something that we really started thinking about and pursuing honestly for the last year.

Greg: It sounds like you're helping people with data driven content, research tools and helping them make decisions. Not making decisions for them, but giving them the confidence in the information so that they can make well informed decisions.

Alli: That's exactly it - creating data driven content that our users can read and understand and have an expert explain it to them in a way that's helpful. And then also tools that help them, let me search this address and figure out what could I rent this property out for? Is the other piece of it. Yeah, that's kind of how this BP Insights vertical within our site, within our product, was kind of born early this year.

Greg: How did you build it? That's a pretty big problem space to take on.

Lewis: Yeah and step zero was really looking at what data we could obtain to help our users. We were able to go out and license data from some industry leaders so that we could then show that to our users. As I mentioned earlier, we have our Ruby on Rails monolith. We had all this data and it's really about thinking what's the user needs? What's the user problems that we could solve with this data? And how would we best present it? We went ahead and started out building a prototype with our Ruby on Rails application. And then as we progressed, we were then able to iterate on that over the year. Obviously there was a significant product element to it as well. Wasn't there Alli?

Alli: Yeah. The product piece was fun and hard. I read this article sometime last year, basically talking about, we've all heard of the MVP, the minimum viable product. What's the cheapest thing we can do that works? And I read this article challenging that idea where users don't really want burnt pizza, they want good pizza. What is our minimum lovable product? What is the smallest cheapest thing we can do that people actually like? And so that was something that we thought a lot about and then created this spreadsheet that I shared with a few other people where we had these scopes of big dreams and then we basically took a machete to it and cut it down, cut it down, until we could figure out what is the smallest, fastest time to value that's actually valuable? And so we built this tool that was super basic, a couple summary stats and a map with a list of links to other properties that we cared about and got it running and then turned it on for, I think, 200 users.

Alli: Really basic and small. And I was careful to target people that were power users so that I knew they would like us anyway, if they hated the tool. And I said, "Hey, this is this thing that we're trying, tell us what you like, tell us what you don't like." And that was kind of the theme of how we went about this tool for a long time - asking users for feedback, feedback, feedback, and then figuring out what can we do with this? What themes are emerging? How can we in bite size pieces, create more value for our users based on what they're asking for and what problems they're encountering in a way that's scalable? The other piece that is just worth calling out a little bit is we mentioned the expert analysis, experts looking at data and then drawing conclusions and writing articles about it.

Alli: We initially planned to launch this, or I think that piece of value, early summer or late spring. And then we realized as coronavirus really ramped up early this year, the economy was kind of in flux. People didn't really know what to expect. It's a scary time and so we realized that we have to launch this now. We have to get something out there now. People are kind of watching what's happening to the economy and are scared and want to know what experts have to say. And so in addition to wanting to build this tool that users would love, there's a big timing piece of this of people would really love this data now. Even if we have less stuff to share, get something out there and tell them that we're thinking about it and that we care and we want to hear what they are scared about.

Greg: That's really cool. And you touched on something that I've struggled with building stuff in the past. I know lots of people struggle with, but kind of that idea of minimum lovable product via minimum viable product. And I always try to explain it as you don't start off building a tire, you start off building a skateboard, then you attach a motor to it and turn it into a scooter. Then you make a motorcycle, then you make a car. But every one of them is something that works and something that somebody can use. You don't just hand somebody a tire and go, "Here, we're building a car." What are your thoughts on that? I'd love to hear your take on how you approach that.

Alli: Yeah, I think that's so important. And it's something that we also were thinking about. How do we give our users enough to get around? To really beat up that analogy - how do we get them three blocks ahead? Maybe we can't take them three miles right now, but how do we provide enough value, enough insight to move them forwards? Which is something that we've been thinking about as we've kind of scaled this tool - what is this first thing we can do that at least gives people an idea? It's not perfect. It's far from perfect, but how can we give them something that's better than nothing that's worth reading? And then going from there is what other insights can we add to this? How can we put a motor on this skateboard? And now we're at this interesting place of, well, we have a motor and a sail, who cares? I don't know, on the skateboard and thinking about, all right, well, I think it's time for a steering wheel.

Alli: We need to give this one a little bit of thought before we move forwards. And that's where we step in with things like usability tests, where I actually targeted users who took a survey, basically gave us bad feedback, but were willing to talk to us. And I specifically emailed those 20 people and said, "Hey, will you help us? Will you look at these things for us? And I'll give you $50, but will you come help us figure out what you're looking for here?"

Alli: And so that's been kind of the theme of the last six weeks for the designer and myself - providing prototypes and saying, "Hey, we got your feedback. We heard you. We know you didn't like it. Let's talk about all of our ideas and things that we can do to build something that you actually want." And so kind of back to the drawing board, but we're taking all those ideas in really bite sized ways that aren't going to take us nine months to build because the time to value is still very real for our business of how much are we investing in this thing that we're not getting value from?

Greg: And how do you protect against dreaded scope creep?

Alli: I am again, really thankful to work with really kind, patient engineers who say, "Hey, that's going to be really hard." And so it's a lot of collaboration between the designer and engineers and myself, where we sit down and we talk about and we research. We've been doing a lot of research this quarter as well of, "Hey, I think we should do this. Can someone figure out how much this is going to cost? How hard it's going to be, maybe any suggestions you may have for taking half steps towards this really big leap." Honestly, it's a lot of conversation and asking engineers for sanity checks or for ideas because the scope creep while it impacts me, really impacts them. And so I'm wanting them to succeed and to like working on a thing where we can realize value and still build something without a tremendous amount of tech debt. It's balance I think.

Greg: It is. It's also, it's a discipline. It's a muscle you have to build. That's one thing I've built projects in the past. I'm like, ooh, look shiny. I can do this too. And then I start coding and I'm like, whoa, whoa, whoa, whoa. Okay, no, no. Comment all that code out. We're doing this. I'll do that later. And so there is a real discipline to I know that this is the skateboard I want to build and no, it does not need sparkly wheels. It can have normal wheels and that'll be fine. We can add the sparkly wheels later and the unicorn and all the cool stuff.

Alli: That certainly happens. This, yeah, we can do that. Should we do that? Is that the right use of our time? Oh, are you spinning your wheels on this thing? And maybe we shouldn't. If it's going to take you more than an hour, we're not going to do it for the next month.

Lewis: The shiny machine learning sparkly wheels.

Alli: Oh my gosh, yeah. The current shiny object.

Greg: Technologically, you probably faced a few issues. You talked about pulling data in from external sources and pulling them into a monolith. How did you approach that? Did you just scale the database and add some more tables and hope for the best? Or did you take kind of a more nuanced approach to it?

Lewis: That was sort of our initial thought, would that work? Can we do that? We're presented with zip files of CSV data essentially.

Greg: Were they FTP'd to you?

Lewis: Almost, almost. Yeah. Actually, yes.

Alli: Yeah, they were.

Lewis: They were. I forgot the part where we put them on S3 ourselves. Yeah. But yeah, that's sort of our raw material and then we had to shape that into the product essentially. Actually very large volume of data. You can imagine data about almost every property in the United States. Hundreds of millions of rows and then associated data with that as well. And we had that early sort of need to allow our data analysis team to query that data as well. We have our data coming in. We want to process it, clean it up, transform it and then kind of got these two different destinations: our application database and a database that's suitable for that querying by our content and analysis team. And so that was moving that data over to initially Amazon Redshift.

Lewis: Yeah, definitely some interesting challenges just with the sort of volume of data. It was beyond the sort of capacity of my disk on my MacBook. That ruled out a lot of local testing that we could do. But yeah, eventually iterating through each kind of step of the process and iterating solutions to the problems that we encountered along the way, really. Rather than trying to spend a big chunk of time upfront and designing something perfect. It was like, how far can we get with what we have and then addressing those problems later on.

Greg: What's next for you guys? What do you see on the horizon other than improving this product and getting the skateboard turned into a Porsche?

Lewis: Well, I joked about the shiny machine learning wheels, but actually we do see a lot of scope for how we can apply that technology for our users. Actually with this volume of data, extracting out of it smart numbers or intelligent numbers based on that data is something we want to do. We already displayed to users, for example, a median rental price for properties in a given area, say zip code, based on, for example, the number of bedrooms or bathrooms that a property has. That's kind of intuition on our part that those features are highly relevant to average rental prices. But really we want to start pursuing a more scientific approach to improve the accuracy of those numbers so that when we present a rental price, we have a lot more confidence that it's based on actually all of the data that we have available going into that number that we're producing.

Greg: That's really cool. It sounds like you guys do have some definite plans going forward and you're tackling some interesting problems. I always like working with tons of data because it's kind of fun.

Lewis: Actually quite interesting, as a Ruby on Rails engineer, there's a lot of times when we don't actually deal with these large data sets. There's a lot of learning that's happened within the team and myself personally. I remember one particularly fun story was when we were sort of importing or reimporting all of our data after we'd made a change to our pipeline. We geocode each property so that's an API request over to the Google Maps API. You can imagine the shock the next day when we saw the sort of $100,000 bill from the Google Maps API. And it's just something that we hadn't had that problem before. Google were very good about it and so on. Yeah, lots of learning that happened around just working with the sheer volume of data.

Greg: Are you guys hiring? If anybody out there in podcast land wanted to come work for you and tackle these sort of problems, are you looking at growing your team?

Lewis: We are. We are hiring for a senior front end engineer. We also use React on the front end as well as Ruby on Rails and a variety of other roles. They're all up on our website at biggerpockets.com/jobs.

Greg: Thank you so much for your time. Again, this is Greg Nokes and thank you, Alli and Lewis for spending some time with me talking about this this afternoon. It's fascinating.

Lewis: Thank you, Greg.

Alli: Thank you.