Looking for more podcasts? Tune in to the Salesforce Developer podcast to hear short and insightful stories for developers, from developers.
106. Growing a Self-Funded Company
Hosted by Greg Nokes, with guests Alli McGee and Lewis Buckley.
Most companies talk about building for the customer—but when you’re a self-funded company like BiggerPockets, building a product that users pay for can be the difference between success and shutting down. Guests Alli McGee and Lewis Buckley from BiggerPockets talk about what it means to truly build a product that delights the customer. They discuss how they’ve structured their teams to collaboratively discover, build, and ship what the customer wants, and how instead of MVPs they build Minimum Loveable Products.
Host Greg Nokes is a distinguished technical architect with Heroku. His guests are Alli McGee, a product manager, and Lewis Buckley, a senior application engineer, from BiggerPockets. BiggerPockets was founded 16 years ago to educate non-professionals about real estate investing.
As a self-funded company, it’s critical for BiggerPockets to create products that customers will pay for. One way they achieve this product/market fit is by building cross-functional teams that are user-focused. All product teams have a project manager, tech lead, and designer that work closely together. This design-led approach allows teams to collaborate with representation from users, technology, and design.
As the PM on one of these teams, Alli lives at the intersection of what can we do for business, what can we do from a technology perspective, and what can we do for the user. She advocates for the customer, bringing knowledge of what customers want, what problems they are facing, and how they have interacted with prototypes in usability studies. Alli also advocates for the business to be sure products make money. Finally, Alli advocates for developers to make sure the project is technically feasible and won’t cause technical debt.
Another way BiggerPockets creates market fit is by creating Minimum Lovable Products—the smallest cheapest thing they can build that people love. With their current product, BP Insights, Alli and Lewis used this strategy to create the first iteration of a product that provides insight into local real estate markets. They then tested the product with users, iterated, and slowly built out a more fully formed offering.
For their tech stack, BiggerPockets is built on a Ruby on Rails monolith. While some in the industry say Ruby on Rails’ time is over, Lewis argues that it has been a great choice, as using a well-known stack has allowed them to worry less about the technology and focus more on building value for users. The BP Insights product was built on this monolith using a massive data set of nearly every property in the US. BiggerPockets imported the data to an Amazon S3 bucket and eventually copied the data to Amazon Redshift for querying.
Links from this episode
Greg: Welcome to Code[ish]. My name is Greg Nokes. I am a distinguished technical architect with Heroku. And today I have Alli McGee and Lewis Buckley from BiggerPockets. Alli, could you go ahead and introduce yourself and then Lewis.
Alli: Hi, I'm Alli. I'm a product manager at BiggerPockets. I've been here for about two years now. I have the pleasure of working with Lewis on our pro membership. It's one of our big membership types - building out tools for BiggerPockets pros.
Lewis: My name is Lewis Buckley. I'm a senior application engineer here at BiggerPockets, and as Alli said, I work with her on the pro team. BiggerPockets is actually a Ruby on Rails monolith. Most of my time is spent building, maintaining, and adding new features to our application.
Greg: That's awesome. And being someone who watched DHH's early Whoops! Demo, building a blog and falling in love with Ruby on Rails, I think v0.7 or something like that. I always love to talk to folks that still have Ruby on Rails applications. Because it seems like to go down maybe a little bit of a tangent, it seems like there's kind of a movement in the industry that maybe Ruby on Rails' time is over, but I don't know if I agree with that or not. I think for some use cases, it definitely still fits.
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.
A podcast brought to you by the developer advocate team at Heroku, exploring code, technology, tools, tips, and the life of the developer.
Master Technical Architect, Heroku
Greg is a lifelong technologist, learner and geek. He has worked at Heroku for over 8 years.
Product Manager, BiggerPockets
Data explorer. User empathizer. Obsessive reader. Idea curator. Believer that products should delight both the user and the bottom line.
Senior Application Engineer, BiggerPockets
From Bristol, England, Lewis has 8 yrs on Ruby on Rails focusing on building scalable backend systems. His spare time is spent cooking & traveling.
More episodes from Code[ish]
Laura Fletcher, Wesley Beary, and Ian Varley
In this episode, Ian, Laura, and Wesley talk about the importance of communication skills, specifically writing, for people in technical roles. Ian calls writing the single most important meta skill you can have. And the good news is that...
Jim Jagielski and Alyssa Arvin
Jim Jagielski is the newest member of Salesforce’s Open Source Program Office, but he’s no newbie to open source. In this episode, he talks with Alyssa Arvin, Senior Program Manager for Open Source about his early explorations into open...
Lisa Marshall and Greg Nokes
This episode of Codeish includes Greg Nokes, distinguished technical architect with Salesforce Heroku, and Lisa Marshall, Senior Vice President of TMP Innovation & Learning at Salesforce. Lisa manages a team within technology and product...