#18: Minimalism Will Make Your Business Successful with Pieter VanIperen
Guest Intro
Pieter VanIperen is the Founder and Managing Partner of PWV Consultants, a boutique group of industry leaders and influencers from the digital tech, security, and design industries. Bringing innovative digital architecture and transformation to our partners in Fortune 500 companies, high-visibility startups, universities, defence agencies, and NGOs.
He’s also an adjunct professor at the New York University on Code Security, and the Senior VP of the Global Head of Cloud Security at 20th Century Fox.
Pieter believes the most important thing you can do to be successful is cut out all the noise and focus on what makes your business profitable first.
What You Learn
- How to identify what is the most important part(s) of your business
- How to cut everything else out
- How to communicate these changes to customers
- How to identify new opportunities and cut them if they aren’t working
Episode Links
PWV Consultants: https://pwvconsultants.com
Transcript
Sean Weisbrot:
Welcome back to another episode of the “We Live to Build Podcast.”
Today, I have with me Peter VanIperen. We’re going to talk about minimalism and why you should stay focused on doing one thing or two things that your company is great at before moving on.
Welcome to the “We Live to Build.” My name is Sean Weisbrot and I’m an entrepreneur, investor, and advisor based in Asia for over twelve years. Join us every week to fast track your personal growth, so you can meet the ever-increasing demands of the company or companies you are passionately building.
Time waits for no one, so let’s get started now.
Minimalism in business (1:09)
Sean Weisbrot:
So, thank you for taking the time to join us today.
Peter Vanlperen:
Pleasure to be here.
Sean Weisbrot:
So, let’s tell everybody a little bit about why minimalism is a great lifestyle choice and how that can affect your business in a positive way.
Peter Vanlperen:
“If you don’t need something, get rid of it.” What that really translates to, in business, is often we set out with these grand ideas as entrepreneurs of where we want to be with this, you know, vision of what is Google or Amazon or this other big enterprise company that’s going to do forty-five things well for people. And the truth is —to really be a successful entrepreneur, you need to find one problem or pain point that you saw for people and go after it, and all the rest of the stuff is just noise.
So, what you need to do very rapidly is identify what is the one or two core things that your business is doing, really one, that is the crux of your business and what you need to do is then look around and all the other ideas you have, whether you’re in an idea stage or you’re literally operating some of these and really eliminate them.
And often, when we come into companies, consulting with people, we often see having been entrepreneurs ourselves, startups to enterprises where, you know, get on the phone with them. And say my favorite is, “Well we have this review feature we need.” “Okay.” “How many reviews do you have?”. “Two.” Okay, “How many customers do you have?”
“100,000.” I don’t think you need to update the review system; you need to get rid of it. And so, I think that it’s really important to focus down on what you’re good at. Go back to kind of the rule of, do we really need this, and really constantly be focusing on that.
Sean Weisbrot:
I personally lead a minimalist lifestyle because I pride myself on being not attached to things. And so, my focus on life is really investing in experiences because those experiences create memories that will take you into different places in your mind and those are things that you can share with others, and it’ll last a lifetime. But things are designed to fall apart and so the less things you have, the happier you’ll feel because, as a famous saying goes, I don’t know who said it, “The more things you own, the more they own you.”
For example, my parents they went to go move their house, and like they’re moving a block away and they needed, you know, a huge truck. They’ve got couches and tables, and beds, and chairs, and desks, and boxes of pictures, and all sorts of stuff. Like, I just don’t think it’s necessary.
Professionally, minimalism is a little bit harder to do, I think because it’s so common for people to want to do as many different things as they possibly can in order to provide as much value for as many potential customers. So, what are, you think, in terms of how does one figure out what they should be focused on? How do they know what to cut out of their business?
Peter Vanlperen:
Listening to you speak, two things really struck me very quickly there. One of the things you said is that you focus more on experiences than on items. There’s an entire field of technology folks focused on, quote-unquote, “the customer experience.” And a lot of what you sit down with, when we consult on customer experience with a client is, okay, I land on this page, what do you want me to do?
“Well, I want you to buy this thing.” Okay. Then, why aren’t you telling me you want me to buy this thing? You have 75 other things on this page, except the experience you want me to have, right? And so, we litter the customer focus with all of these other items. On top of that, what people often don’t realize when they are inspired with an idea, is, that is exactly what happens when you create all of these things as a business. If you need to move them, you have to move all of them, you have to maintain all of them, you have to upkeep them.
Because that’s the other thing too, it’s not just that you have a chair and if that chair breaks you know like, yeah, we don’t need another chair. If that chair breaks, now you have, you do have some customer base that will use that chair, and if you get rid of that chair they’re going to groan and complain, and most business owners are going to give into that. I see that often even giving into it at the point where it’s an expense for them to maintain it and there’s literally no revenue lift from having this feature. They just want to quote unquote, “keep the customers happy.”
And I think that it’s really important to realize that you can’t be the business for everyone, even the big businesses that we think of that are the businesses for everyone. One, they didn’t start out that way but, two, often there are folks who just don’t like them at a certain point, and you’re not going to win those customers over. So, I agree with you want to give as much value as you can to your customers, but the question is “who is your customer?”
What/When Should you drop a feature? (6:40)
Sean Weisbrot:
You said something really interesting, and I want to follow up on that. You said sometimes there’s a feature that a user likes but adds no real value to the business. How do you tell the client that you have to get rid of this thing, and how do you guide them to telling the customer that uses the system why this thing is not going to exist any longer?
For example, Google does a great job of building useless crap and then throws it out there, and then suddenly cuts it after they’ve got you know tens of thousands or hundreds of thousands of people using it. Nobody really liked it, they were just kind of using it, I don’t know why they were using it and then out of nowhere, “sorry we’re gonna cut it,” and you know bye. How does a company do it better?
Peter Vanlperen:
I always lean on data. When there’s a feature like that, you’re almost always going to find that it’s not really being used, right? You have 100,000 customers, 10 use it, they might use it religiously daily eight times a day, but then, two also talking through that the fact that those 10 or 100 people use it religiously might at least increase the cost and maintenance of it, or the level of complaint if things go wrong with it.
So, there’s kind of a data journey there that usually, we take a client on, as far as convincing the customer, it’s really about pointing the customer back to the core experience, and I’ll be frank, it’s not going to work 100%. We like to put it as it’s a feature trade-off and we try to make a weighted trade-off is what we call it. So, on the one hand you’re losing this thing that you love every day, on the other hand we’re going to announce that at the same time that we’re adding this other thing that hopefully is highly desirable which softens the blow of losing that feature.
At the end of the day though, you might have those 100 customers run. Now, if those hundred customers are making up in some weird business model you have, 80% of your business, then that is a core feature, right, that is a core feature. However, if they’re more likely, if you have 100,000 customers and this is less than 100 and they’re making up less than 1% of your revenue, if you’re lucky, then you take that hit. But over time, removing that, is the expense of maintaining that, having to deal with the problems with it, customer complaints etc., the cost will offset. And so, I think it’s, again, it’s a data journey and it’s looking at like the longer-term view of what your business is. There’s always an unspoken expense here of focus, both on the business’s side and on the customer’s side.
Sean Weisbrot:
How long do you give a feature before you decide whether or not to get rid of it?
Peter Vanlperen:
Instantly, right? The cheapest time to cut a feature is in its absolute infancy when you’re devising if it’s an idea, right? Many people will forgo sitting in a room and really giving themselves the hard litmus test of saying, does this actually fit with our business, does this actually procure revenue, does this actually truly increase customer engagement or happiness or some sort of key progress indicator? A lot of the times, ideas are very kind of ethereal and mushy, and throw stuff at the wall. Let’s see if this works, which is a very agile mentality, but there’s costs involved there.
And we see this a lot in startups where they’re throwing things at the wall until they run out of cash, so I think you really have to have that hard conversation in the room before when it’s on paper, before you’re even doing anything. I think, short of that, you need to put it out there. And there’s this other idea of like, I’m gonna drop a feature, everyone’s gonna magically find it. It’s this magical thinking of the internet, right? What people don’t realize is the internet even on your own website, you’re basically shouting into a black hole, right?
Because they’re speaking of focus, I mean there’s literally more websites on the planet than there are people right. So, there’s a million things, probably hundreds of billions of things to focus on online, and so, how do you draw that person’s focus? And a lot of times you see these tangential features with not really a lot of fanfare or anything except maybe a highlight in a navigation menu, maybe some email blast that’s gonna go into a spam folder and be ignored. If you’re going to put the money and time and effort into this feature, you should be promoting this feature and launching it.
And then to come around to answering, you know, the original question, how long? If you’re really promoting the heck out of this feature, it becomes really quickly obvious from both a budget standpoint of the money you’re spending promoting this feature, and the return you’re getting whether this feature has value or not, and that’s painful. It’s a lot easier sometimes to just throw it out there and hope and pray and wait for people to find it and use it. But the reality is, they’re not and so you’re just prolonging a decision you’re gonna have to make.
Feature trade-off (12:08)
Sean Weisbrot:
You were talking about how you would advise a client to have another feature ready to announce when getting ready to cut the feature that people are probably not using that much, but there are some that are holdouts. What if that company doesn’t have another idea? What if they don’t have another feature ready? What do you do then?
Peter Vanlperen:
I use the term “feature” loosely. It’s really about having something to announce with your hit list, right? And so, if you orchestrate this well, most companies adjust at least several things in a year. Most businesses do not just run statically for, you know, years on end. So, maybe you’re gonna adjust pricing, hopefully, it’s not a raise in pricing, you’re gonna add free shipping, you’re gonna something, some cookie, some a little bit of something that you’re changing that is a positive thing to give to the customer, and then you offset that with the hit list, right?
And so, what you’re really trying to telegraph to the customer which is true. You are removing A, B, and C and you’re getting X. And X doesn’t have to be some full-blown pitcher, X could be, “hey, if we get rid of A, B, and C, we can make X a dollar cheaper.” It might not seem like a lot but maybe you pay us a monthly membership and a dollar is a lot, and you can probably do that if you’re not maintaining A, B, and C, you know. We’re making up a circumstance here, but again, the idea is to look at what is the offset you can offer and we kind of try to look at it in the opposite mean when you’re going to have positive things, right?
Many customers come to us with, “we need to make a bunch of changes”, some are going to be positive and when you’re done talking to us some might be negative, at least to that minority of customers, but you’re gonna be able to go out and push that out to people and really have that offset. So, it’s not necessarily we need to go and sit in a room and think of something to replace this, it’s, what are the activities you’re already doing that are positive that you can announce to a customer and then at the same time you’re doing that. Let’s look through our list of weird stuff that we really don’t want to have lying around the company anymore. In other words, let’s ask the question, do we really need this list of things, if not, can we get rid of it and then attach that hit list to that positive announcement.
Evaluating business path (14:44)
Sean Weisbrot:
So, it’s interesting, you said that talking about looking for things to get rid of. We’re currently nearing the end of the development of the MVP for our platform, I find myself talking to investors a lot of whom say, “hey, I really like what you’re doing but I need you to be a little bit further, like I want to see users on your platform” or “I need to see data on user engagement, meaning not just have users but actually go a little bit more deeply you know have a few months of data generated and then share that with me.”
So, what I find myself doing is looking at the remaining road map for the MVP, and what’s supposed to come out after in the next six months. And I’m thinking about what I can kind of cut out of that road map, so that we can get to users a little bit faster, so that we can get to those investors a little bit faster.
You’re talking about focus on the things that are going well and cut out the things that don’t go well and try to figure out as quickly as possible how to know if this thing is not going to work out or not. But what if you have a core business and that business is doing crazy good at what point should a company decide whether or not to move laterally or to move into a new vertical?
Peter Vanlperen:
We tend to often hear the mythology and the legend of the companies that took big swings in a different direction. The story that I like to lean back on is the story of Amazon. Lots of people look at Amazon and they say, “well you know they were a bookstore and now they do everything, and they have AWS and everything else.” All of that change happened incredibly incrementally, making little shifts in each direction. Even going back to an email Jeff Bezos sent to his valued users, basically saying “hey, okay, you buy books through us, what else do you wish you could buy through us?” And those were the things they went out and facilitated.
They didn’t just go and say we’re gonna offer every product, they didn’t, you know. AWS was developed out of a need to have better, you know, hosting and infrastructure, and uptime, and things like that as their site was growing, right? They needed to take over more of these things and then they realized like we’re doing these things. We could do these for others, there’s kind of a natural progression and lean towards these things and I feel like if you’re lost there, and you’re not really sure what the next step is, to then go back to the data. And if you don’t have the data, do what Jeff did, which is, go out and gather the data.
But I feel like companies that tend to take big swings into other verticals, the conglomerations, they don’t really work that well often anymore. And actually, if you go back and you look at the last like, I want to say 10 to 20 years of kind of buying and selling companies, you’ll actually see that there are a large number of companies that bought what seems like really successful or potentially profitable enterprises, and then several years later are spinning them off for pennies on the dollar.
And there’s a laundry list of these stories and often it’s because the things they’re buying, and the things that they’re, the verticals they’re trying to get into, it’s not their core business. They don’t know what to do. They don’t know how to run it. They don’t know how to optimize it and in some cases like the best thing that they can do is kind of just leave it be, and we’ve seen in some cases that would be successful, then you’re really truly becoming like a holding company or conglomerate and so that’s not really a next step, that’s just that’s an investment. Does that make sense?
So, I think that you need to take small steps in a direction and see if you have success that are varied off of what you’re doing. And you need to really look hard at the data to figure out what your next steps are. Your customers who spend the most money, what else do they like? What else do we know about those customers? What else is close that we could serve those customers on?
Sean Weisbrot:
I think that’s really good advice, thinking about, you know, how else to better serve your customers. I think Jeff Bezos did a pretty good job there.
Dogfooding (18:58)
Peter Vanlperen:
I’m a huge advocate of the concept of dogfooding, and I find it that there’s definitely certain company scenarios where it’s hard. Listen, if you provide loans for construction and, you know, your developers are not all going to be house flippers, however, I think it’s really important that people get in the mentality of kind of dogfooding their product. And if they don’t, if they can’t be their own customer because the product doesn’t fit them, then they really need to try as much as possible to have everyone on their team really invest in understanding their customer and their customer mentality.
And also, having customer champions that are, that are internal or semi-internal, external, internal who are partners with you, who are trusted, who come in, who maybe, they get your product for free or etc. but can come in and particularly dogfood your features for you. And again, that goes to the earlier you can get rid of it, the earlier you can flush it out, the better off you are as far as kind of limiting spend on the wrong direction.
Sean Weisbrot:
I’m sorry, what do you mean by dogfooding?
Peter Vanlperen:
You work at a restaurant, you make food, you taste your own food and you want to eat your own food. Dogfooding is the concept of everyone has to use your own product. You need to understand the pain points of the software you’re developing, right? And so, likewise, if you’re never your own customer, you don’t know what your customer is going through, you don’t know what your customer’s journey is.
And I’ve literally gone into situations where I’ve sat in rooms with executives or product folks, we’ve said “okay, well, where do you do this on your site,” and they don’t know, they can’t find it. And often, it’s like the QA person who has to be their own customer because that’s their job, who’s like, “oh you go you click here, and then you go through here, and then you go in this menu.”
You know if you really think about that, that’s a little bit ridiculous, you’re very out of touch if that’s the case. And so, how are you possibly gonna know, again, if that idea that you’re coming up with in that room is gonna pass that litmus test of do you actually need this thing if you don’t even know where the things you built are?
Sean Weisbrot:
Yeah, that makes a lot of sense.
Importance of communication (21:29)
Peter Vanlperen:
Early in my career, I worked at one point with a UX person who brought a number of pages that they thought they had made look extra better and enhanced the customer journey. Ninety percent of it was small light text on light backgrounds and we sat in a room, and they presented this, and they were all very excited. They worked very hard on it and all of us who were experienced with the customer and the client base looked at them and said, “listen, the average customer who could like contributes to 70% of this business’s revenue is over the age of 60, they’re not going to be able to see the text that you have on the screen.” And the designer was frankly embarrassed.
But again, it’s because at that time in that culture, there were only a handful of people in that entire room who knew that. I think it’s important to have transparency for, you know, developers and everyone else on the team.
One of the things we preach at our company is this philosophy of you know, radical production transparency, and we can get into that. But, you know, at the core of where most of these things break down is being really truly transparent, and so, a developer should know what you’re doing well as a business and not, and your customer base because without knowledge, without transparency, and without that shared communication, the more and more often you guys are going to be shooting blind at each other and no one is going to be stepping into the room doing that litmus test going, “yeah, I don’t know if we really need this. I don’t know if this is really the right direction.”
Sean Weisbrot:
Yeah, I think it’s really important to communicate with your team about what they’re building and the why. When I first started with Sidekick, I didn’t do that, I didn’t realize that I needed to do that. I thought that they understood because I was handing them these, you know, wireframes and opening issues on Gitlab and telling them what the things needed to be doing. What I was missing was this higher level of “we’re building a task manager, here are the features in that task manager, and the reason why we’re building it is because it’s going to help the user do y or x.”
After I hired my COO, he came in and he did a very deep review of the company from many different angles, interviewing every single one of the employees, you know, to see what their experience has been thus far. And one of the questions he asked them was “do you understand what we’re building and why?” and he said that none of them knew. So, after that, I realized that I needed to explain more clearly, and so, that got me developing release plans that are much longer out so they could see that for this release plan, we’re going to be building this feature set, and for the next release we’re going to be building another feature set.
And so once we got to the point where people could see what we’re going to be developing for the next year, we could build a story around that, and explain to them why it’s necessary for us to be building these things, so they could understand what the user is going to be experiencing and how they connect to each other since everything we’re doing is meant to be seamlessly integrated, all of the features have a reason, and they’re connected to each other for another reason.
And so, once we did that, it became much easier for them to become emotionally invested in what we’re doing. Even though before that, you know, they were enjoying the development and they liked the company culture and all that, it’s just that we were missing this really important internal communication piece that may have been affecting our efficiency because they didn’t know why we were building stuff.
Peter Vanlperen:
Software development is a business where someone can be completely isolated and fragmented from the rest of what’s going on and in many ways still do their jobs, but it’s a little ridiculous when you look at how we build other things there’s not gonna be a situation most the time in the real world where someone’s laying bricks and they don’t know if they’re laying it for a barbecue pit, or they’re laying it for a church, right, or a home. But in software development, we have this frequency to say to people, go off in this corner and go do this thing, almost you don’t need to know why, just go build this thing and, you know.
For us, one of ways that we prevent that, going back to kind of the real-world metaphor there, is everything that we do, and it sounds similar to what you guys have kind of come on to. It starts with a really, what many people in like the agile world, other people would criticize us, and it is a really over developed plan to start from. But I want to be clear, it’s not like a giant, you know, 140-page waterfall document, but it is a 10-to-15-page plan of what we’re going to build, why we’re going to build it, what’s included, what’s not, what are the ideas here, what should we be getting rid of etc., that everyone can go back to and kind of understand. And included in that is literal like background information on the client, the context of the project, what is specifically in scope and out of scope, and why.
And so, it delivers and answers all of those questions that as a developer, you know, if you’re out there just laying bricks at some point you have to be wondering, “what am I building,” right, “what is this stack of bricks going towards,” right, and “am I using the right mortar to lay these bricks” and I might not know I’m guessing if I don’t have the larger picture to look at.
Sean Weisbrot:
I use Gitlab, and we’ve got milestones, and we’ve got the issues inside of the milestones, we’ve got very brief descriptions inside of the issues with, you know, maybe a mock-up, explaining what the features for what it connects, to what’s the expected behavior links to other issues from the back end, or the wiki documentation, so they can look back and see how the API needs to be implemented; things like that.
This release plan gets broken down into sprints, so as far as I’m concerned, it’s not terribly detailed, it’s just detailed enough to get it done.
Follow up with Peter (27:50)
Sean Weisbrot:
What’s something that you’ve learned recently that you’re working to implement?
Peter Vanlperen:
We’re always internally adjusting and looking at our own gaps. We start with a plan but how many tickets do we actually start with, and what is enough to get going, and where we feel comfortable with that.
Sean Weisbrot:
How can people keep up with you on the internet? What’s something that’s important to you that you think they should know about?
Peter Vanlperen:
Uhm, pwvconsultants.com/blog. I usually post security or technology, and sometimes it’s me just ranting my opinions about technology, and do you want to get to know a little bit more about how I think? That’s definitely the place to do it.
Sean Weisbrot:
Great! Well, it’s been fun. I really appreciate this conversation; I think there’s a tremendous amount of value in here for everyone.
So, I guess we’ll leave it at that. Thank you very much for taking the time to join us today, and something I like to say for every episode that I record is “entrepreneurship is a marathon not a sprint.”
So, take care of yourself every day.