The right mindset is the most important thing as a successful CEO. Join Doug C. Brown and Ben Johnson, the founder and CEO of Particle41, as they discuss the CEO mindset, how it differs from a tech mindset, and how to adapt for success. They also discuss frameworks and simplicity, how to launch a new product (or boost an existing one), and much more.
Benjamin Johnson is a serial technical co-founder with a track record of success and hands-on open-source programming experience. He has a wide range of being both a board-level advisor and founder but also an in-depth understanding of how things work. Through his 20+ years as a software developer and leader, he has gained extensive experience with remotely distributed development teams and business hacks. Currently, Benjamin is the CEO & Founder of Particle41, a dev firm founded by industry veterans that aims to help companies accelerate their initiatives through Software Development, DevOps, and Data Science. With a constant focus on results and ways to improve, Benjamin is having fun building highly scalable and highly secure applications.
Visit his website: www.particle41.com
I’m bringing you another amazing guest. His name is Ben Johnson. @BenjaminRJohnson is his LinkedIn profile. He is the CEO of a company called Particle41. They’re a software development and tech services business for development. I brought him on because we were going to talk about two things. One, how do you go from a technician’s point of view, somebody who worked within the company on the tech side or from the development side and then transition into a CEO? What’s the actual pathway and mindset that we’ve got to have in order to pull that off successfully, which he has. That’s A.
B is it started going into, how do we launch a new product? For those of you who have products that are existing and you want to upgrade them or products that you’re thinking about, what is the genesis of that whole process? We talked about those two points in detail. Without further ado, let’s go speak to Ben.
Ben, welcome to the show. Thanks so much for being here.
Thanks. I’m excited. I’ve been looking forward to this.
Would you tell everybody what Particle41 does and what you do there so we can set the frame for this?
We’re a software consultancy. We focus on software application development, data science, and DevOps. If you have any business needs related to software, we’re a good tech partner for your venture.
Thank you. We’re going to talk because you’ve done this going from what we’ll call step zero to a startup or from a technician to a CEO of a startup. I have found that many people have challenges with that transition. What’s the difference between starting up from ground zero? Let’s take it from the technician’s standpoint. From going there and then having to become a CEO of a company, what’s the genesis or the transition of mind that has to happen there?
When I started my career, there were a lot more things that we had to do to be able to serve products on the internet. My first company was an online travel company back in the early 2000s. We had to do a lot of work to get the travel website out the door. Fortunately, the market has evolved. There are things like the Cloud available to us and things like modern software frameworks that we can know about. It’s been easier to learn those things and then not have so much work to do on the tech side.
It’s the evolution to good strategy around product development and making sure we’re not wasting time in the market, and understanding how to speak to people holistically and tie what we’re doing in the software and software team to their commercial roadmap and aspirations. Being able to bridge that gap has been super important.
That’s interesting. I want to dig into that a bit. Holistically, what does that mean in the terms of software or in the terms of what you do?
When we’re advising CEOs or CTOs, what we’re looking at is do they have a roadmap. Do they have an org chart? What’s their mission? What are the corporate goals? We’re trying to pull all of that together so that we know why the teams that we’re providing are iterating. What are they fighting for? When you’re a developer, your reward for doing a good job in this particular iteration or with this amount of work at hand is that in a couple of weeks, you get more work. That’s your reward. You keep going and living to fight another day.
We want to make sure that our developers are tied to the client’s mission and that they understand what it is. What I always say is my teams do best when they’re crushing mountains of work, but we need to work with our customers to develop that mountain of work so that our teams inevitably succeed. When we do that, we’re looking at what is their go-to-market strategy. What kinds of features are the clients saying? What are the customers saying?
We help them with both product ownership and strategic planning for the product. We’re getting the work done. The worst thing when you’re a techie is the right code that nobody uses. We want to be able to help the clients see around corners. I and my leadership team have many years of scar tissue, so can we help them with some of those common mistakes?
I find something you’re saying interesting here. What I heard was that you plan from an operational point or from a development point. You call it development, which a lot of companies would call that operations and delivery.
Technical operation is a fair term.
You’re looking at the CEO outcomes or the outcomes of the business from that standpoint and then everything else is rolling in from that delivery point. Am I getting that correct? The reason I’m asking is a lot of companies look at it from the sales perspective that they’ve got to deliver it, and then when there’s a handoff to DevOps, it’s not always clean. When you’re coming at it from the operations side, then sales must understand what the operation side is doing. Therefore, the delivery seems to be far more congruent to a client than it would be if we started with sales and then dropped it on ops.
We are constantly trying to connect a desired outcome to the work. Staff augmentation is a common model. Paying per person per month for some teammates is a common way to price software development services. We’re not reinventing the wheel there, but what we are doing is wrapping it in a layer of expertise and results-orientedness that makes us very different in the market.
I had to come out of my shoes as a technologist over the years to figure out how to pull that out of the CEOs and CTOs that I work with so that we could be there for them with exactly what they needed when they needed it. We’ve recovered a lot of projects for in-house teams that over-engineered the solution. They were trying to build the perfect system rather than listening to what their CEO or CTO was trying to accomplish in the market.
Back a couple of years, if we rewind before VC money was so easy to get, you would go back to the dawn of time when bootstrapping was this common buzzword. All the YouTube videos were about it. We’ve lost this era of bootstrapping or figuring out what is the true MVP. Over the past many years, our MVPs have gotten larger and there’s been a failure to launch because of that.
We’ve found a lot of counsel in saying, “Don’t manage to a big bang. Let’s bring it down to something that we can deliver. Have a customer use it and give us feedback. Let’s then pick up a feedback cycle that aligns sales and product development to be a common thread or a conduit between the customer and your technical delivery.”
When I work with SaaS companies, the coolest thing that I can make happen is that a customer says, “I wish right here you had such and such,” and I can turn that around in days, not weeks, not months. The sales guy can go, “We heard you. Your feature was such a great idea. Your suggestion was such a good idea. We’ve returned that.” They may have 5 or 6 other big features that they want you to do, but because you got them that 1, they’re willing to hang out, keep subscribing, and let your roadmap take its course.
They’re in with you from a customer loyalty standpoint because you heard one thing that they said that you could quickly execute. That’s something that has come out of this CTO-to-CEO transition where I can leverage my strength of getting software delivered quickly and tie that into the sales process. It builds more feedback from the customer. There are more opportunities for us to win. We can help the end customer feel a part of our process.
When somebody is developing a new product, whether it is software, which is what you specialize in, or it is anything, they’re coming out with a new product. This may not be even a fair question to ask, but I’ve got to believe that there’s a set, like a core number of 2, 3, 4, 5, or whatever the number. If the market is looking for these things, the market will tolerate them while you build the rest out. Do you have a number or a quantification for that?
There is an adoption curve. You could look at that bell curve that the MBA school would say, “This is an adoption curve.” As you go on listening to our customers and building the features that they’re asking for, then you would float up the adoption curve. Maybe the first people you talk to don’t come in until you’re 6 to 8 months into this process. You should be building that pipeline. You should be nurturing them or sending them out roadmap updates.
You might have talked to them a few months ago and they’re signing up because you finally said something about QuickBooks integration. It could be that one thing that they super needed that you heard them on and they’re ready to adopt. It should follow your adoption curve. If you’re doing your sales right, you should get a glut in your pipeline, like a lot of committed AR, and then see that come into closure as the features are produced. As a CTO, I would want you to be on point or it is your name against that. It’s like, “If we build these features, we’re going to get this demand that we’re seeing in the pipeline.”
I’m purposely skewing our show here to this new product launch-type thing. I’ve had so many people come and say, “I would like to have an expert who understands new product launches.” You are an expert in doing this because you’re doing this on a consistent basis, whether it be software or we’re going to run a manufacturing company, an auto dealership, or whatever.
If I understood what you said correctly, you were going to start the marketing and sales process prior to the development of this and get a glut of people into the pipeline. You will then try to release this off to a certain number of people, in this case, software, and they’re going to take a test drive. They’re going to drive the vehicle around for a while and tell you, “This is great. The suspension is awful. We need an FM radio versus a serious satellite radio.” It could be whatever they’re telling you. You are going to then validate that with the future potential buyers and tie all this in. That’s how you continue to keep updating your product. Did I get that right or did I miss something?
You did get that right. In the beginning, you may have to offer a freemium product to get that interest and establish that. You have to give them some kind of value exchange. Back in the bootstrapping days, they were even trained to do tests with eBooks or LinkedIn surveys. We’ve gone past that where we deliver something, but I love the idea.
I’m encouraging entrepreneurs to start small. Start talking to your users. Start building up that pipeline. Work with a dev team that can deliver an agreed-upon prototype within 90 days and a functional MVP within 120 to 150 days. You’re trying to pace a minimum viable product, and then showing that to users and seeing if it’s making a change in the business.
SaaS is tough because there has to be a direct SaaS exchange. Tech-enabled services, if they’re offering a service with human capital and they want to button it up with technology, that becomes a little easier from a financial planning standpoint. Both tech-enabled services and SaaS services could benefit from this kind of agile model.
When you’re saying the latter, the human capital into a tech fulfillment, give me a couple of examples of companies maybe that are doing something like that.
You would see this in a brand like LegalZoom. They’re doing your LLC formation for you. They’re keeping your company in compliance. They could take your money and go do it manually with human operations or they could take it in through a website, put it through some kind of process, and make it easier for them. What they’re doing is they’re trying to take the per-order ops time or human capital time from some amount per order to next to zero per order.
We work on a lot of projects that are building technology around a service that could otherwise be delivered with blood, sweat, and tears. We’re trying to put tech around that and make it more patterned, more standard, and less human. It is so that the people that you are hiring to run your business can do other things. They can manage more clients on a scale.
That’s what I mean by a tech-enabled service. The great thing about tech-enabled services is the service side can be revenue-generating very quickly. You can take orders for that service. When they have robots to do plumbing, you’ll see an evolution in the plumbing industry. With digital services, there are certain things that could be done online or complexities that we can capture. We can order a cab on our phone and we take it for granted. Even Uber is an example of a tech-enabled service. There’s so much technology that the service part of it you don’t even think about anymore.
That’s interesting. Can any or almost any business do that?
If your business model is SaaS, then you have to have a product eventually that a person is willing to pay a monthly or annual subscription for. The gavel comes out a little more often on your SaaS product. Is it offering the value that somebody is willing to pay for that supply and demand? Is it digital supply and demand? Are they signing up? Are they adopting the SaaS software?
Let’s face it. SaaS businesses are not for the faint of heart because you don’t get paid until your software is good enough. That is where giving them something for free, loading up your pipeline with committed ARR based on features that the real people say they would use when you have them, and getting started on that pipeline and getting started with your ICP or Ideal Customer Profile is important to do, I believe, early. It is sometimes before you do have a completed product to market.
We’re speaking to Mr. Ben Johnson. He owns a company called Particle41. You had said something earlier about stepping out of your own shoes and stepping into a CEO thought process. You went from CTO to CEO. You’re thinking differently. How does one make a transition like that? Is it out of like, “I need to morph into something so I’m going to try it?” Is there maybe even a pathway for somebody to think about doing this? A lot of people that I’ve talked to go, “That’s fear. What if I mess it up? What if I don’t succeed?” How do people frame their minds and take the step?
There are some great things in engineering the idea of the process. In software, we use frameworks. Frameworks take away choices from us but they give us simplicity. There’s an exchange of choice for simplicity. When I look at certain business problems, I try to figure out what the framework is. That mixed with some first principles.
When you’re in tech, you’re focused on a solution. Give me a problem and I’ll give you the solution. I’ll go attack that solution and be dead to everybody while I’m hyper-focused. In tech, the focus is currency. Give me a mission and I’m focused on that mission. As a CEO, I’ve had to come to detach and look at the layer above the solution or why and use frameworks. OKRs are great. If I can come to an agreement with what my customers’ OKRs are, that’s fantastic. That’s a good partnership mechanism. I understand what kind of goals in the market they’re trying to accomplish and then we can fit solutions to that.
It is also thinking about that strategy and the strategy elements. It’s a process. It’s a series of discussions that we’ve defined that’ll help us get to deliverables around the roadmap, org chart, and what kind of staff you need. We are guiding the overall structure of the business into the solutions that need to be created for them to succeed.
Frameworks take away choices but create simplicity. That’s what I heard you say. Is that accurate?
Why would we not want frameworks in any business? A hospital is a business whether people agree or not. The reality is it’s to serve patients in a capacity and move them through there as quickly as they can. They get them healthy, get them out, and get paid. That is a framework. It came to me and I’m like, “Is there a business that should not create frameworks?” That would create working leverage within the company and consistency, which would create less stress. I can hear people going, “What about innovation?” The question that I have is, should all businesses be looking at frameworks more so?
I think so, anytime you can bring it down to some simple core values or these simple frameworks for understanding things. The reality is we get dug into the details. I used to think that to be productive, I needed to be writing code that day to have a productive day. I measured my productivity in a given day as the number of lines of code that I would write. That was as a tech guy.
As a CEO, I’m more focused on what are the decisions I’ve made or how have I helped other people unlock decisions so that they can keep moving towards the goals. That can be either our goals or our client’s goals. I’m constantly looking at better ways to communicate where we’re boiling up details. Development is a detailed gardening type of career. You’re in there writing lines of code to represent details that represent rules or standards in an actual business. That’s not something that a CEO needs to occupy themselves with. They need to say, “Where are we trying to get to? When are we going to be done?” We need to figure out simple ways of conveying that to our buyer that helps them move forward quickly and know that we got this.
Could I classify a technician or people who are not at the CEO level, many of them, that it’s more of a get-it-done-and-be-accurate or get-it-accurately-done? A CEO then has to think more about how to make it more efficient, how to optimize it, and how to create leverage to get more done with it.
Fundamentally, how could I be 4 to 6 weeks ahead of my team? Especially since we’re in a remote world, one thing that we’ve been finding across the 31 active teams that we have is that the teams that have enough vision to be 4 to 6 weeks in front of them with more detailed design and requirements around their work are the hyperproductive teams. The ones that are having to circle back and ask the business, “Is this right? What do you want us to do next?” are costly to a business.
We are trying very hard upfront to help the business plan out and have a vision so that the work order or what they should work on is ahead of where they are. Even if you weren’t in software development, what would it look like to be 2, 4, or 6 weeks ahead of your team in terms of what they need from you to be successful? That would be a huge exercise for many business owners.
If people want to get a hold of you or know more about the company or anything like that, what would you recommend? How do they do so?
I’m on LinkedIn as @BenjaminRJohnson. They can also email me at Ben@Particle41.com. I’d love to talk to any entrepreneur that’s trying to get to the next level. You don’t necessarily have to need to develop a product, but I’d be excited to talk to any CEOs or CTOs trying to succeed.
Ben, thank you for being on the show.
If you think about a technician, it is somebody who accurately gets things done or the person who delivers and gets things done. You could then think about the CEO. As the CEO, you’ve got to stay 4 to 6 weeks ahead of your teams in what they’re thinking. In other words, the CEO is making things more efficient and optimized. The CEO is thinking about ways of generating leverage, money, and profitability. They are also thinking about how to support the teams of people that are working for that company who either directly report to the CEO or report to somebody who reports to the CEO. That is a different thought process.
A lot of people, especially when they’re the startup person in a company, start out and think like a technician because they have to. They also think like a CEO in some regards, but they only have themselves or maybe 1 or 2 people. It’s all about sales in every business and driving it forward. As you start to grow the company, then, as a CEO, you have to change your mind a little and then a lot and then shift it from, “My job was this as the technician, but now it’s going to be this.” Sometimes, a lot of people I’ve found fight that process. It takes them a lot longer than they want to have happened. It’s because they still know the technician’s role. They’re holding onto that because no one could do it better than they could. That’s usually part of the challenge for them.
The second thing is when you’re bringing a product to market, we laid it out pretty simply. You want to keep it simple. It’s about going to market before you go to market. In other words, it is developing a client base before you even develop into the MVP and the development so you can get feedback on what people are looking for. Get paid subscribers and then you can organically start funding your technology build-out if it’s technology.
If it’s not technology, you can do the same thing with a non-technology product. You can still get subscribers and still build out the base, and then launch it. The challenge is so many people are impatient and they’re not willing to go through that process. Traditionally, you’ll miss a lot of stuff that you didn’t have to build, so you’ve spent money that you didn’t have to and took time where you didn’t have to. The second thing is you may run out of runway space that way. In other words, you have a cash burn of whatever. You want to continue that cash to be strong and not burn out of that. Thus, not making it through that process.
If you love the subject here on this thing, I would ask you to go give it a five-star review if you like this episode. If you, yourself, or someone else is an expert, has expertise in a certain area, or you want to hear about a certain thing for shows like, “I would love to know more about this,” let us know. Either we’ll have you or your expert, or we’ll find an expert to cover that show. What we do is listen to everyone. When we get enough inquiries on that specific subject, we go out and source the expert for you so we can bring that show to you. You do that by sending an email to us at YouMatter@CEOSalesStrategies.com. We will respond to every inquiry that comes in.
If you, yourself, or someone you know wants to get themselves into what we call the 1% earners category through selling, in other words, you want to be at that top 1% of earners or you massively want to shift from point A to point B, we are releasing a 1% Earners Academy. It is coming out where we are going to teach you how to do that.
We’re also developing a SaaS product, which is a prospecting automated and automated meaningful follow-up system that leads to conversions. If you’d like to be on the waiting list for either-or, reach out to me at Doug@CEOSalesStrategies.com. Let me know and we’ll get you access to get to the waiting list. We’ll communicate with you as we’re going along. As always, go sell something. Go sell a lot of it and sell it profitably. Play win-win. Help them win and help you win at the same time. It’s the best relationship. It spawns more referrals and more regeneration of repeat business long-term. Until next time, to your success.
By opting in, you authorize CEO Sales Strategies, LLC to send you email communication regarding the requested ebook and other relevant ebook resources. You can unsubscribe anytime.