Prodity: Product by Design

Ben Johnson is the CEO and founder of Particle41, a dev firm specializing in software development, DevOps, and data science. In this episode, Kyle and Ben explore the interaction between product management and software engineering, and how important both are to product development. Ben shares his journey as a serial entrepreneur and his approach to balancing work and life through the four pillars of faith, family, fitness, and finance. He delves into the importance of agile scrum processes, the role of a fractional CTO, and the significance of outcome-based communication in business. We also discuss the challenges and strategies for app modernization and team formation, exploring the importance of blamelessness and system optimization.

Ben Johnson
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.

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.


Links from the Show:
LinkedIn: Ben Johnson
Books: Building a Story Brand
Links: Claude.ai, 99designs
Site: particle41.com


More by Kyle:
Follow Prodity on Twitter and TikTok
Follow Kyle on Twitter and TikTok
Sign up for the Prodity Newsletter for more updates.
Kyle's writing on Medium
Prodity on Medium
Like our podcast, consider Buying Us a Coffee or supporting us on Patreon

What is Prodity: Product by Design?

Fascinating conversations with founders, leaders, and experts about product management, artificial intelligence (AI), user experience design, technology, and how we can create the best product experiences for users and our businesses.

Kyle (00:04.286)
All right, welcome back to another episode of Product by Design. I am Kyle, and this week we have another awesome guest with us, Benjamin Johnson. Welcome to the show, Ben.

Ben Johnson (00:16.11)
Yeah, hi, thanks for having me. It's good to be here, Kyle.

Kyle (00:19.134)
It's great to have you. We're very excited to have been on the show with us. Benjamin is the CEO and founder of Particle 41, which is a dev firm founded by industry veterans that aims to help companies accelerate their initiatives through software development, DevOps and data science. And obviously there is a lot to talk about with that and with your background.

But before we do that, why don't you tell us a little bit more about yourself?

Ben Johnson (00:51.374)
Yeah, so I really enjoy helping folks with their technology decisions and then technology execution. So I'm a serial entrepreneur and usually partnering with companies as a technical co -founder. And then in 2014, I started a service company to really focus on that for just really to help more businesses simultaneously than get totally devoted to a single business. So yeah, we...

We really love crushing mountains of work, whether that be advisory or execution. We just, we like getting work done.

Kyle (01:30.174)
Awesome. Well, I'm excited to talk more about that because there's obviously a lot to what you do and some of the things that you have done. But before we dive into it, why don't you tell us a little bit more about what you like to do outside of work and outside of the office?

Ben Johnson (01:44.75)
Sure. So I think the best to describe that is in, I believe there's kind of four pillars or I try to balance myself with four pillars. Those four pillars are faith, family, fitness and finance. And so I'm just trying to hit a little bit of all of those every day. You know, it's easy for me to, you know, spend 60 hours a week working. I think for a lot of folks, that's, that would be easy.

But to make sure you hit all four of those things each day takes some discipline, but it also leads to a lot of joy.

Kyle (02:20.862)
Very nice. Well, I'm interested, we may have to talk a little bit more about that, because I'm interested in how you do balance some of that. And maybe you can tell us a little bit more about that right now. Is it something that you look to kind of balance every day in kind of the work that you're doing, or is it something that you kind of spread over time? Because obviously balancing work and family and fitness,

Ben Johnson (02:40.878)
Bye.

Kyle (02:50.302)
Like you said, in finance, there's kind of that push and pull constantly. Is it kind of a daily thing that you're balancing all of those, or is there kind of over a timeframe, you're kind of giving more to one area or the other? How do you balance those things?

Ben Johnson (03:08.078)
Yeah, so I think the four again are faith, family, fitness and finance. For me, I can get faith and fitness done as part of the morning routine. So wake up, get some exercise, spend some time with faith -based meditation. I read my Bible, I pray. And then, you know, before the days really got going, at least I have those two things out of the way.

On the family side, this is where I probably need a little bit of improvement. But what I attempt to do is make sure that I'm having at least some moment with, you know, with my two kids or I have four kids, but two of them are kind of kind of grown and it's hard to spend time with them anymore. But with each of my kids to have some kind of whether it be a nighttime ceremony or just some form of regular routine with them, getting them to an event.

But I check the box when I've done that and then, you know, some kind of affection passing with my wife, whether it just be a small note or, you know, maybe a household, you know, favor or something I can do to that I know she'll notice just to make sure her cup is full. But that's kind of how I see it. I want to check those boxes or take inventory of each of those things each day.

Kyle (04:29.95)
Okay, very nice. Well, I'm excited to kind of dive into a little bit more about probably, we'll talk probably more specifically about one of those areas, which is probably what you kind of bucket in the finance area, the work area. But maybe you can tell us a little bit more about, starting a little bit back, how you got into technology and kind of what you're doing now. So, what got you into this path of

Ben Johnson (04:44.494)
Sure. Yeah.

Kyle (04:59.07)
you know, technology and software and kind of where you're at right now.

Ben Johnson (05:03.662)
Yeah, so I have been in a bunch of industries and really in that technical co -founder C, tried to accelerate a business as fast as possible through a product strategy or roadmap and then agile software development execution or digital execution on the other side. And so I did a travel company. I did two media companies, one in travel and one in finance.

And then I also did a legal services company and sold it to LegalZoom. And each of those things was a common thread of setting up a team to accomplish business goals through digital tech. And now my partner, who's been with me across that entire journey, he and I work together. He's the CTO of Particle 41. And we love to help businesses define their product strategy.

define their product roadmap and help them accelerate towards those goals that could be anything from reducing costs by maybe being more efficient in how we deliver a service or fulfill a service to how we deliver that service online.

Kyle (06:18.174)
Okay, that's, you've touched on a couple of things that I think are really interesting. And I think for me, you know, some of the product strategy and the product roadmap are kind of these fundamental principles that are really core to a lot of things that I think about all the time. And I think are really foundational or fundamental to creating good technology and good

products. I'm interested in how you think about that as you're helping companies and helping products and software or whatever it is that you're developing. What are some of these things that you're or maybe some of the foundational parts as you're going in and helping companies or as you're developing things? What are some of the fundamentals that you're focused on?

I think you probably touched on them a little bit, but what are some of those fundamentals that you're helping companies and teams really focus on initially in order to ensure that they're focused on some of the right things?

Ben Johnson (07:31.982)
Yeah, so first off, the thing I like to talk to the executives about is high value versus high need. Think of it like, you could also think of it as market uniqueness, you know, what is gonna make us truly different in the market. And I think those are the things that should be the most custom, especially when you go around and normally if you're in a business trying to fill a need, you don't.

you feel like you're doing it in a special way. You don't generally do that in a place where there's tons of competition to do exactly that. You have some differentiator. And so thinking about what are your differentiators and what are those user experiences? And then thinking about those being more custom, like those are the things you're really going to invest in. So what I've seen some companies do is they'll, they'll,

maybe subscribe to like Salesforce or they'll subscribe to NetSuite or some ERP type solution, which gives them a robust platform. But then as they try to extend that functionality to the user experience, it doesn't quite connect. And so what we try to show is, okay, well, whatever you're giving to the customer, that's probably the thing you want the most control over. That's the thing you should spend a lot of time designing. And so we want to put a lot of attention in that. Things that are high need.

are like in digital, we know we're gonna need to host some stuff. Why not choose the best to breed partner like Amazon, web services or Azure to do that layer of things. And then we end up in this really cool middle layer and we're in kind of the, you know, the SaaS Renaissance here where we got tons of SaaS tools for any little thing. So many available platforms to help us with, you know, we always use Stripe for payment processing are almost always, you know,

Or if you need accounting software, you look at QuickBooks. So we also help customers look at the competitive landscape around those what I call core platform technologies and make really quick but solid decisions in those things. Like, what are we going to do? And then help that be seamlessly integrated so you can deliver that custom layer on the top. But the end customer doesn't know that you're leveraging different technologies below.

Ben Johnson (09:56.206)
And I think figuring out that stack is really helpful to acceleration because then we know that, okay, these capabilities exist in the market. They're not market unique, but we need to leverage them in our product. So we have this kind of thick integration layer where we're getting all those values from all of those relatively low cost things. And then we're packaging them up to be differentiated to our customer. And that's, I think that's really essential. And,

In my last venture in legal services, we were able to go from literally almost nothing to an acquirable company in three years because we were able to do that partnering in the right places to accelerate the overall.

Kyle (10:46.494)
Yeah, I think that that's really good because a lot of times it's easy to get bogged down, at least I've seen, in a lot of the other parts and not focus kind of like you said on what is the key differentiator or what are some of the key differentiators that you're delivering as opposed to all of the other pieces and what are some of the other providers that can do some of those things as opposed to what is it that...

What's the value that you're delivering as a company that really differentiates you from other people or other companies in the market? And how can you focus on that and really make it unique and really great compared to other offerings in the market? And I think that that's such an important thing. As you've worked with companies, I'm interested in...

Maybe what are some of the difficulties that you encounter as you work with companies or teams and you see them trying to build new products or new technologies or even scale technologies? Are there some things that you see frequently from teams or companies that are trying to do some of these things, some maybe underlying themes that are fairly common?

Ben Johnson (12:09.422)
Yeah, there's so many ways to answer that question because I think there's like all these little things. And so maybe I can do a quick survey here. So we are big subscribers to the agile scrum process. We just feel like that's one of the best ways digital products can be delivered. So establishing that process, one of the first things we see as leaders, you need to allow your team to plan a couple of iterations ahead.

What that looks like is, from a leadership perspective, is thinking about what is my team going to work on next week or next month, rather than what are they working on today? And so, as leadership, you need to have done the hard work to get out in front of your team. Because especially in a post -COVID world, most teams are remote in digital execution. And so, if you're baby birding is kind of the metaphor that I use. If you're baby birding or spoon feeding,

slightly more negative way to say it. Then you do have queuing or wait time where the tech team, the execution team is waiting for instruction. And so really, I think in any business where you're trying to produce a work product, you need to be out in front as a leader. You need to be talking about next month, not this month. The team needs to already know how they're executing current work.

And so I think that distinguishing between current work and future work is really important. And doing that little bit of planning. You don't have to plan out a whole year. You just need to be one step ahead of your team with your intention. I think that's super important. Getting people to estimate work or try to predict work by hours never works. So we try to use a relative measure like points.

Big believer in that I think when we ask how long when we ask somebody how long will this take? If I feel a little more like a hero kind of personality then I'm always gonna be like I'm calculating my weekends in there I'm gonna work through the weekend to get this done and so I'm not gonna give you an accurate estimate or I have some personal barriers around some additional pressures in my life, so maybe I'm gonna try to get give myself a pressure relief by overestimating.

Ben Johnson (14:34.222)
So it just never works. We need to compare work to itself. We need to give it the Dave Portnoy one bite pizza review type, where we're really comparing the other pizza we tasted to each other to get the perfect score. And I think when work is estimated in that way, you get accuracy and predictability. So those are a couple of things that I think we really stress on that deliver productivity. And

I think to some organizations productivity is there but predictability is kind of the next horizon. So we want to get there and I think those two things help you get both.

Kyle (15:14.558)
Yeah, I think that you've touched on some really interesting topics in, you know, one, getting to the estimation, which is really difficult because we're very, as humans, we're just bad at estimating in general. But getting to the predictability, which is an important part of...

being able to do work. And it's not about, like you said, being able to plan a full year in advance, but being able to just have some amount of predictability in kind of the work that we're doing. Maybe tell us, we've touched on this a little bit, tell us a little bit more about Particle 41. What is it specifically that you do at your company?

You've mentioned some of the coming in and doing some of the dev work, but what is the full suite of things that you do and you focus on app particle 41?

Ben Johnson (16:20.526)
Yeah, I mean, I think in summary, we love to crush mountains of work. I mentioned that before, but, and so I help with CTO advisory, getting the playbooks. We have a small team of people who have been CTOs before. So there's four of us right now and that team is growing where we, we exercise a lot of CTO advisory development management.

If maybe there's just something not quite right and you just want a second opinion about how things might work within your organization So many folks focused on saving money and getting the most out of their dollars right now So we love to just come alongside you and help you figure that out Then we also form execution teams We have teammates in the US India and the nearshore markets so we can arrange a team

Maybe you need more product ownership or project management onshore in your time zone. So you can have somebody there shoulder to shoulder with you. But maybe because of cost consciousness, you'd like to use some of the distributed labor market to lower costs, right? I'm just being direct. And so we can kind of put a team together that makes the most sense for you. And we establish the Scrum Agile process and we crush mountains of work.

Within the different technology that we're solving for, there's tons of different things that we do. We don't really have a core special language or core special framework. We love jumping into problems and delivering the best solution.

Kyle (18:06.078)
Got it. And you do one thing that I'm kind of interested in because this is part of what you do is that you mentioned like the second opinion or the fractional CTO work. And I think that it's a fascinating thing because I feel like it's becoming more and more prominent, especially as like you mentioned, there's just more...

Ben Johnson (18:21.71)
Yeah.

Kyle (18:35.966)
At least I feel like I'm seeing more of this kind of flexibility in a lot of things that we're doing with more of the remote work and more of this, the hybrid and just more of, I guess, some of the cost consciousness as well. I've been seeing it on the product management side as well, where we're having just more of this uptick in fractional product management as well. And so I'm interested just in what you've seen kind of on the CTO side.

I've worked with fractional CTOs as a fractional product manager. And so seeing this becoming more and more of a theme that I just, I don't think it was there or nearly as common in the past, but becoming more of a common theme. And so I'm interested just in your take, what you're seeing as it's becoming what I think just more of a common practice or something that is.

starting to take shape more than it has in the past.

Ben Johnson (19:37.326)
Yeah, different times call for different measures, right? I think there can be a zero equity way for founders to bring their ideas to life. And especially when you're trying to achieve product market fit, just getting some key things set up from the beginning. In our co -founder kind of CTO as a service kind of offering here.

One of the first things we do is just help the executive team set up goals and OKRs or SMART goals, kind of choose a goal setting framework. Just like, hey, where are we targeting here so that we can create a plan that's directional? The beauty of working with service firms is you get some of that executive expertise and they can share the cost of that across multiple clients. So.

You know, our CTO advisory starts at like 5k a month. It's not expensive, but to do some of those things correctly from the beginning that set you up for a good relationship with, with investors. Maybe you need to, you've never done an investment deck before, but, but you have all the workings of, you know, of a decent business. You're starting to earn revenue or you're starting to get a product in line. So.

The CTO advisory, I think, is a great way just to make sure that you're setting up for success and it's not necessarily, you know, we price it so that you may still have room for starting a team and doing some execution. And then to not part with your equity, if you're the idea holder, I just think it's a tremendous value and we're super excited to do that. We've also rolled in in kind of a venture studio way.

to the first round. I'm never the lead, but I will roll in sometimes if the customer really showing that ability to raise money and the ability to make revenue with their idea. And we're kind of progressing down that thing, then I'm usually excited to be part of that initial seed or safe round.

Kyle (21:54.494)
Right. Yeah, I think it's absolutely fascinating. And like you said, the right tools for the right opportunity or the right time and place and just seeing kind of the evolution of this and being able to kind of use different things and different tools for different needs and different times and places. And it's just making more sense to have lots of flexibility in order to.

do different things in different ways. And so I think it's a fascinating thing, kind of like you were mentioning.

Ben Johnson (22:27.086)
Yeah, it's a stage appropriate decision making. So another thing that's happened in the CTO advisory is they got a team of 10 that's working on a super challenging problem, but they have no predictability. So can we look from a dev management perspective and see what's going on? And do we need to tweak our estimation process? Are we saying we're agile, but we kind of lost some of that discipline? Or what is that, right?

And we also do a lot of app modernization. So there, Hey, there's this legacy application. It's serving a purpose. It's making revenue, but we're starting to fail our security tests. We're just aging our teams kind of aging from an expertise perspective a little bit because we have been kind of holding onto this older piece of tech. And that's okay. That's great. There's a lot of great, exciting businesses that are running on stuff that's 15 years old. So can we.

create a plan that moves them from that to something that's maybe completely security compliant in the cloud, cheaper to manage, break a monolith into microservices. We also look at challenging problems like that and set up a factory approach to migrating that into a better, newer world without necessarily customer disruption. Just keep all the trains moving on top.

Kyle (23:53.886)
Yeah. And I'm interested in that. How do you go about bridging the gap for some of these, whether it's a large task or maybe even just a small one, but really going from some of these ideas to the execution or the go to market, because that can be for a lot of customers, I imagine, like the big hurdle or the big task. And what have you found to be some of the keys really

in getting over the finish line of, you know, we have really these big things that we need to do or, you know, these mountains of work and really getting that to, you know, into the hands of customers or over the finish line or whatever it is that really needs to be done and getting it out the door and into the hands of users.

Ben Johnson (24:43.086)
Yeah, I think a lot of times we think that our problem is so unique and our problem just must be super special. Really what that is, is that's like a lot of fear of change and what may happen if we disrupt our customers. When we're successful, then there's a lot to lose. And so a lot of times it's not about new methodologies, it's about doing the methodologies that work.

Well, it's kind of getting back to fundamentals. So one of the things we'll do is we'll just break down the inventory of capabilities. So if that's things that the app already does, we'll just functionally deconstruct it. And we'll kind of say, hey, we know that all these things are still going to need to work in the new world. Or you want to build a new app that has all of these different capabilities. And we have a process for inventorying that.

And then just quickly saying, okay, well, if we give every one of those a certain amount of attention, some small, some medium, some large, and give those some amount of attention, then it's going to be X, right? It's going to take six months and four people or, and that tends to bring some, okay, this is possible. We also talk about just the methodologies for that particular problem. So.

One thing that generally makes people feel a little more comfortable about a daunting task, you're just talking about how the task could be automatically tested. What kinds of things can be tested? What kinds of things need people to test them? But once they give it some thought of how can I automatically test this change and see if it's working and almost start with what does success look like and write some testing that says, hey, am I moving closer to success?

That tends to help folks with complex problems as well.

Kyle (26:37.534)
Yeah, I think you've touched on a few really interesting things in being able to break down some of these really large things into their manageable components and then being able to test them. And then really just being able to say, you know, none of this is necessarily new or unique and being able to say this, you know, either we've done this or this has been done.

by others and it's a very doable thing. I know as I've worked across a lot of different products and projects that you start to see those themes and they become not unique to any specific company or product and it becomes almost the, you know, we've seen this before. This is a doable thing and it's not unique to any one company or any product team. Like these are themes that...

everybody's dealing with. And that can be like a reassuring thing to companies or teams that, hey, I've seen this before, like we've done this before. And it's, you know, it doesn't have to necessarily be a huge daunting task because other teams have dealt with this, like other companies have dealt with this, like we can deal with this too. In, you know, it may still be like a large time consuming thing, but it's not, you know, it's not.

brand new to the world, like other people have done this and we can do it too.

Ben Johnson (28:09.742)
Yeah, exactly. I think the one company that we worked with, they had 280 applications. They needed to move all those applications from their aging data center, on -premise data center to the cloud. And there was a lot of reasons to do that. Mainly, they were not stable. So lots of downtime. Hey, we can get you in a better place. It's OK. Let's look at which set of these applications

lot of these problems end up in the like the law of thirds where out of those 280 applications really the ones that they were toiling over and changing frequently was one -third of that 280 so take those and put some extra care and attention into those those were easier to modernize because they were changing them and they had more aspiration to make

the code modern, and so we created a modern environment for the modern code, right? And that, okay, well, cool. Now we're just dealing with the other 180 applications remaining. And then a third of those were hardly ever used. Like people really didn't want to claim them. They just, they were just sitting around. And so, you know, you kind of take out the other third, you know, you run a marathon one mile at a time. But I'm sure most marathon runners,

I'm not one of those. When they get to mile nine, they're like, I'm a third of the way down. When they get to halfway, I'm halfway there. And those resets allow us to just think about what's remaining. And I think that's the kind of operation we're trying to do with these big modernization projects is just chunk it up and handle it one thing at a time. And when we do that, we can move really fast.

Kyle (30:01.982)
Yeah, definitely. Now you kind of touched on this a little bit in really the importance of taking some time before you get started to look at all of the project or the product or the scope of work and thinking through it, doing some of the initial work before you even get started to understand and look at...

How is it that we want to break this down? How is it that we want to approach this? How have you found that to be beneficial both for the work that you're doing, but also for helping others understand the importance of maybe taking some time initially before diving in and just jumping into actually doing work, but taking some time to break things down and actually figure out what it is that you're going to be doing and how you're going to be approaching it.

before you get started.

Ben Johnson (31:03.758)
Yeah, it's super important. I think one project we're working on right now, it kind of starts with the must -haves. And the old way was, OK, let's go plan out the whole project, like everything. Even at the beginning of the project, you can easily define things that you know you need for sure. Most applications will need authentication and authorization. They'll need a login. They'll need a forgot password. They'll need an account of some sort.

So there's a lot of common ground that we can just, as that planning process and that breakdown is happening, there's things that can go ahead and be worked on as the design and the further planning are coming together. But I think in that initial planning, just, hey, what capabilities do you envision? Breaking those up, prioritizing them a little bit is super helpful. And those don't really even need to be.

that detailed, just enough to kind of get a gist of them. So we do that kind of t -shirt sizing, small, medium, and large, break that down, then determine, okay, which ones of these are like, there's no question that we're going to need these certain sets of capabilities. I even think phrasing them as capabilities gets the different stakeholders, even if they may be from non -digital backgrounds.

More engaged like capability. Okay, I can talk about capabilities And then You know, we're also finding tremendous value in Letting people brainstorm with one of these meeting assistants on board like get the get the transcript Don't just try to remember everything but get the transcript let people just brainstorm With one of the like read AI is the one we use otter is another one?

just letting people talk out what kind of talk about these capabilities. So you can refer back to that. You can ask that transcript questions through your favorite AI tool. You can really get the most out of brainstorming. And so they don't feel like they're having to make every request for every little feature. If we can kind of decide on these higher level categories, then we can do our best work as product owners and...

Ben Johnson (33:23.15)
developers and CTO people, we can start to do some of the solutioning around that. Like, this might get you what you were looking for. And we can do it also with modern best practices, because we're not the first person to create a lot of these capabilities. There's so much out in the market that we can learn from and do that next stage better.

Kyle (33:44.798)
Yeah, I think that that makes a lot of sense. Now, you mentioned that as you go into these projects and you're engaging with companies or organizations that often you're putting together teams based on what they need, whether that's a product or a project or whatever it is that they're looking to do. How is it that you go about...

you know, forming a good team that is going to, you know, have the right capabilities, but also going to, to be able to work well together. You know, what are, what are some of the principles in, you know, forming and maintaining a good team that you found as you've been putting together, you know, new teams and, and as they've been working together over time. and you know, maybe as you've run into conflicts, like how have you overcome some of those things? Like, well, what are some of these principles that you found?

both in forming and maintaining good teams.

Ben Johnson (34:47.757)
Yeah, it'll be a little bit classic MBA kind of an answer, but in execution, it's not like that. Defining the RACI matrix. So for folks that aren't familiar with RACI, R -A -C -I is kind of the thing. Like, let's just be clear about the roles and responsibilities of the different teams. And we even have a product called the Turnkey Team. The Turnkey Team is basically...

says, hey, we know we're probably going to need front end dev work, somebody to really focus on user interface, somebody who's going to do the back end work. We need some kind of QA to be represented. So we're going to have a QA person. And then we also need some form of DevOps or infrastructure support. So we kind of talk about that anatomy of the team. And that varies only slightly depending on the product and the project.

But generally, you need to kind of think of these different roles and responsibilities, and we have a framework for that. Once we define those roles and responsibilities, that really helps everyone to know. And then on the stakeholder side, are you an approver? Or are you really your role, like that product owner role? That's what I find most businesses having the toughest time because we're here to really accelerate the development.

But we need all of those planning and decisions to be made around how do you want to price it? How do you want to... You're going to have a subscription. What does the subscription include? There's so much around the business model that we need as input in order to continue to move quickly. And so I even have a slide in my proposal that really says the importance of the product owner.

And although we can offer those kinds of services, we really ask the client if they would consider having that person on their side as a permanent part of their business. So this thing that they're building has ownership. And I think ownership is such a big word here, having people own their spot and understand their role and then speaking up.

Ben Johnson (37:08.398)
and being creative and having good craftsmanship are all essential parts of that. And then I think on the backbone of all that, you mentioned some of the interpersonal stuff, is this idea of blamelessness. Blamelessness doesn't mean lack of responsibility, because we just talked about defining roles and responsibilities. So that's clear, you're responsible for these things. But one of the easiest things for a business to do is say, well,

You know, if my product was better, I would sell more. Or if my tech team was better, I'd be more productive. These are unfortunately hindrances to learning what the actual root cause of the productivity or their performance issue may be. And we all live in this kind of symbiotic system, right, of team collaboration. So we've got to really look for where do those improvements need to be. And if everybody has this idea of, hey, I'm not going to blame anyone.

But I am going to look for the importance. Medical industry, 10 years ago, had huge issues with this. Putting something that would kill you next to something that would help you and then blaming the nurse because she grabbed the wrong one. They both start with A, they're organized in alphabetical order, but one thing's harmful, one thing's good. Let's put them right next to each other and see if anything bad happens.

And I think sometimes in digital execution, we do that. We put the knives together with the spoons. And then when somebody cuts themselves, we say, well, you're not part of the team. And that's just not the case. Most failure is lemony Snicket. It's a series of unfortunate events that leads to the failure. And so I think diagnosing that carefully is really essential.

And then teams, I think, flourish in that kind of environment where, OK, we're not just trying to find blame. We actually just need to make improvements so that we can all do what we're responsible for in a safe, productive way.

Kyle (39:17.15)
Yeah, I think that that is such an important thing. Making the system work for everybody in it as opposed to, you know, just continually trying to make the people work within a system that isn't necessarily working for them. And, you know, like you were saying, continually blaming the people in the system for grabbing the wrong thing instead of grabbing the right thing, you know, when the two are right next to each other. It's just...

rather than do that, let's make the system work for the people and have it in such a way that it makes it very easy to do the right thing because most people want to do their best work and want to do the right thing most of the time. And so if we make it very easy to do the best work that you can do and do the right thing most of the time, that's what most people are going to do. And if they're in a system that promotes that kind of

you know, behavior and promotes the best type of work, it makes it very easy to do. And if we can change that kind of system, then, then, you know, good work is, is much easier to do. And let's look at the systems before we are constantly blaming the person or blaming the team for not operating in a way that we think that they should be when it overall may be a much more systemic problem that like you were saying.

Ben Johnson (40:41.55)
Yeah, and I think we see this came out of this idea of blameless post mortems. Hey, we missed the deadline, but we all agreed to the deadline, by the way, but we missed the deadline. What happened? What went wrong? How did that work? Or just the idea of a retrospective where we're not, nobody's individually to blame, but we're just talking about how we could do one better on the next round.

is the essential part of the storming, forming, and norming that we need to do as a team.

Kyle (41:15.294)
Yeah, I think that that's great. Absolutely agree. Well, I'm interested, you know, is there anything that you wish that you knew earlier in your career that you have learned over, you know, over the time that you have been, you know, working or, you know, co -founding companies or working with other companies that you know now that you wish you would have known earlier?

Ben Johnson (41:42.446)
that's a good question. I think, you know, right now I'm super into like the idea of marketing and community building. and I feel like I'm a little late to start that game and, it's also, you know, the market is tough, right now for everyone. And so,

I'm developing some of those outward communication skills and brand building. And one of the things I've just discovered is building a story brand by Donald Miller. And I've just fallen so in love with this concept that as I look across the marketplace, I see everybody wanting to describe features and describe services and, you know, just describe. And then you put this certain amount of ownership on.

the listener to map that. And, you know, sometimes we call it geeking out, right? Like what you're really doing is you're just regurgitating all this really cool information, or actually it's data, and you're not synthesizing it into information. And so I think there's this data versus information thing that I've constantly had to remind myself of and then teach my team. Like I don't want the data.

I want the information. I want to know what are we trying to make a decision on? What are those pros and cons? That's very informative. Data is just like, here it all is. You got to figure that out. Donald Miller in building a story brand, he really talks about the correct perspective. What I believe is that we're the client is the Luke Skywalker. We're the Yoda. Yoda is still really cool. One of my favorite characters.

but that they're the hero of the story and you're here to guide them. And this prevents you or this kind of blocks you from, hey, let me just give you all the information I got and see if it works for you. And I think that's been a huge course correction for me. Even, you know, materials that I've written even months ago are now like, this is awful. Cause now I'm looking at it through the lens of being a helpful advisor.

Ben Johnson (44:01.23)
instead of this lens of, let me tell you all the things that I can do. When I do that, I'm the hero of the story. And there's several, there's numerous cases in business where a business tried to be the hero of a certain situation. And it just, it typically always, you know, it fails because the customer is the hero and we're trying to help them get where they need to go. And I think that...

That's been an essential mind shift, especially when it comes to external communication that's been helpful.

Kyle (44:39.006)
Yeah, I think that you're absolutely spot on with that. And I have been thinking about that a lot, especially as I'm dealing with lots and lots of data that is needs to be made much more into kind of like you're saying a story. How is this relevant to the people who need the information? And it's much less about lots of data and much more about what is this telling people who need

the information and it can't just be like a data dump. It has to be what is relevant specifically to them. It can't be just everything and you got to make sense of it. It has to be made sense. We have to make sense of it for them so that they can just see it and understand it. And, you know, that layer has to be before so that, you know, there's not this cognitive load of...

I have all of this and now I have to try and understand and make sense of everything that you're trying to tell me.

Ben Johnson (45:38.542)
Yeah. Like the next time your mom or you're at a dinner party, I'll just use the mom example because it's more fun. What do you do exactly, your mom asks? And if you try to describe to her, well, I take the product requirements and I turn them into user stories and I manage the developers, she's probably checked out and just, I love you, son. I'm so proud of you, right? You know?

But if you were to say I help people get their I help get this particular application into the market in three months. That's something even your mom can understand it. Wow, you know, you did that. That's really great. And now you're getting instead of the universal, you know, all moms love their son platitude, you're getting an actual like, okay, I've just connected with what you you do, because you mentioned an outcome.

rather than the action, right? And I think the outcomes over actions kind of idea is super helpful in communication. If we can kind of tilt our mindset. I mean, even if you go ask, try GPT for marketing collateral, it'll just pump out the service descriptions and the, but if you say, no, describe this more based on outcomes, you just get a completely different result.

and a better product, I think. And so, yeah, focusing on the outcome. I work with a lot of engineers and a classic thing with the engineer is to start in the middle of the problem. And, okay, give me context. And so, when you're solutioning, you need all that. You need the context, the beginning, middle, and the end. But in introduction, I think if you start with the outcome, it's a lot more helpful. I wish I'd been better at this.

Earlier on, I think that's a huge key to success, that outcome -based communication rather than action -based.

Kyle (47:40.798)
Yeah, absolutely. I definitely, definitely agree with that. Well, Ben, this has been a great, great conversation. And I do have a couple of questions that we like to kind of wrap up with. But before we do, is there anything that we talked about or didn't get a chance to talk about that you'd like to add?

Ben Johnson (48:02.254)
no, man, I, this has been great talking with you. I, I like to, I think answering your questions has been great. It's also really cool to talk to somebody on the prox side and, and, meet up with them, and connect because, you know, I just, I really appreciate what you do being more of an engineering led organization. I really appreciate all of that fact finding and digging into,

digging into the customer's business that folks like you do that help us succeed in execution. So I appreciate your background as well.

Kyle (48:40.03)
Awesome. Well, yeah, this is, it's great. I love, you know, the product and engineering, getting together and talking because it's, it's two sides. It's the two, it's two of the sides that, that help to make, make things happen. So it's, it's great having these discussions. So, to start to wrap things up, you know, we, we like to ask everybody if they have read or watched or listened to anything that they found particularly interesting and

This does not have to be business or technology related, but it can be if you like it.

Ben Johnson (49:16.334)
I think the Donald Miller building a story brand, go check that out. That's good stuff. That is business related.

Ben Johnson (49:29.518)
I have been kind of in a hole for a bit on just kind of focusing on marketing and sales and external messaging. I will give a shout out for Claude AI. I find it to produce much better outputs than ChatGPT. So I'll give that a shout out. Just as a brainstorming assistant, one of the things Claude does that I find...

fascinating is it allows you to use file attachments as a kind of prompt. So we'd definitely check out Claude AI. And then also, I think just for small business folks, 99designs is still thriving as a really great designer marketplace, Fiverr. We like to use those for our internal projects for our marketing.

things like that so Nobody there's no shortage of people who can help you get your ideas to market

Kyle (50:37.886)
Yeah, those are great and definitely agree on both the AI side, cloud is a great one and there's, like you said, a number of them out there and then some of the tools as well, some really great ones. So we'll put some of those links in the show notes as well. Where can people find out more about you, about your company or any of the things that you're working on?

Ben Johnson (51:05.678)
Yeah, I would just start at, of course, I'm always at reachable at ben at particle41 .com. Super approachable just directly through email. But also check out our LinkedIn page. It's easiest to find me through that LinkedIn page just because there's tons of Ben Johnsons in the world. And we're pretty active on LinkedIn.

And then we're hoping in 2024 to start our own podcast that will be called the particle accelerator And we should have our first episode going live soon

Kyle (51:41.662)
Okay, awesome. Well, we will put those links in the show notes as well. So you can check that out and you can connect with Ben on LinkedIn and on email and on his website. So we'll put all of that in the show notes. Ben, it has been great talking with you and I think this has been a great, great discussion. So appreciate all of your insight and everything that you've shared.

Ben Johnson (52:05.006)
Yeah, thank you, Kyle. It's been great talking with you.

Kyle (52:07.838)
All right, and thank you everyone for listening.