E84: Why Software Engineering Will Become More Commoditized

No and low code tools continue their explosion of growth.  They are becoming more specialized and capable. 

I believe this to be because software engineering has been the bottleneck on development teams for some time. 

While custom engineering isn’t going anywhere, the future of the role is likely to change.  Let’s talk about the opportunities that might create for product teams.

If you want to find product-market fit faster, sign up for my free 5 day email course here – https://nxtstep.io/fit

Episode Transcript
Hey folks, Sean here and today what I want to

talk to you about is why I think software engineering

as a skill set is becoming slightly more commoditized and

what that might mean for product teams everywhere.

So I’m sure my product teams are

fairly familiar with this, but for the

longest time now, the biggest bottleneck product

development has typically been the engineering component.

As in it takes the longest amount of

time in order to go from our designs

and our required experiments to actually getting those

features and functionality into the application itself.

As such, over time, a significant amount of

resources have been placed here trying to figure

out how to do so faster.

And there’s been all kinds of invented models and

new tools that have come to market, enabling us

to be able to speed this process up.

Here everything from the Lean Startup kind of revolution

all the way to and through what is commonly

referred to as no code or low code platforms,

which I’ve dived into and pretty significantly as well.

Also I’ve leveraged them for a number

of my client projects and we’ve built

some pretty comprehensive and impressive products using

some of these platforms like Bubble. Bubble.

IO is kind of an ecosystem, if you will, of

being able to build almost an entire application, if not

an entire application, that has the look and feel of

being able to be pretty significantly customized, but is largely

a no code or low code platform, meaning that you

don’t really need to write significant amount or really any

code at all in order to create the kind of

experience that you’re looking for.

Which again, if you are heavy with tuning into

some of my content, you’ll understand how important I

feel that that is for us and our role

as product leaders to make sure that the experience

that our product ultimately delivers is optimal and matches

essentially solving the customer’s top problems and pain points.

So because that’s the area of focus, it’s really

important if we have an opportunity to place most

of our resources and focus there because that’s ultimately

what we’re doing on the back end in terms

of how the technology works.

And self admittedly, I’m an engineer myself and I have

a lot of respect for the work that engineers do.

However, having said that, recognizing the fact that

it has been the bottleneck, these applications have

grown significantly in that their popularity has grown

pretty aggressively because this has continued to be

a challenge for product teams, especially when looking

to do something new or create new features

and functionality and want to speed up the

product development production process.

These tools have enabled us to be able

to do that and that pattern continues.

Very recently, I’ve read about a product

called cumul.io, which has raised Series A

over $10 million very recently.

And that is a tool that enables

you to incorporate some essentially more advanced

analytics and bi type tools for business

intelligence capabilities into SaaS platforms.

But to do so yet again as a low code platform,

which is pretty advanced capabilities as it pertains to low code

or no code platforms, but an all important one because still

yet a bottleneck on the demand side is how do we

process and get the best type of information out of all

of the data that we have now?

Because there’s an overwhelming amount of data in

the world and not enough processing power or

capabilities to really better understand and extract information

from it, which is typically the desire.

So products like Familio which are specialized,

and bubble which are more generic, are

providing us with essentially an ecosystem worth

of options when it comes to building.

Now, there’s still a place

obviously for custom engineering, right?

If you need a product to scale as aggressively as

something heavy like a salesforce or a HubSpot or something

like that, your NoCode platform is not typically going to

be able to handle that type of volume, at least

not yet, and may be able to do so eventually

if this pattern and trend continues.

But for now, your custom engineering will enable

you to benefit from operational efficiency at scale.

However, before you get there, when you’re trying

to experiment and you’re trying to test new

products and things like that, if you want

to speed up the product development process.

So far the trend has been no code and

low code platforms seem to be here to stay.

They continue to be able to raise money,

they continue to be adopted by product development

teams and they continue to enable teams to

move faster in the development cycles.

So what I’m trying to explain for you here is

that how I see this pattern developing over the past

few years and where I think that it’s going and

then I want to talk more about what I think

that means for developing product teams and the changes that

might become so if this trend continues.

What it will mean for product teams, in my opinion,

is that as I’ve thought about how it gets broken

down before in terms of responsibilities on a product team,

I usually do so in three different ways.

I would put the what we are intending to build and

why we are intending to build it into the product category.

So product managers and product people

who are interacting with customers and

users to do research and discovery.

It’s our responsibility to figure out what the priority

is, to build what the problems we’re solving are,

where the obvious unmet needs are those types of

things, and then work with our engineering or development

teams in order to prioritize those for development, which

I would consider to be the how.

As in how are we going to capitalize on that

opportunity, how are we actually going to build that, how

are we going to bring that experience to market?

So that’s where I draw the line most of the

times, the what and the why lives on the product

side, the how lives on the engineering side.

What I’m continuing to see more of, especially

in the early stages of this work, is

that the how is becoming more commoditized.

And I think that is happening because it’s, for

quite a while now, continue to be the bottleneck,

as in folks have wanted to move faster.

Everything else is accelerating, yet that’s

what’s taking the most time.

So much of the innovation has gone into that space

in terms of figuring out how to speed it up.

And I think that’s where we’re seeing a

lot of this development come from in terms

of low code and no code platforms.

As such, over time, I could see teams changing to

be less engineering focused, more product focused, as in the

new bottleneck, which I think is still something that doesn’t

happen all that efficiently, if at all.

On a lot of product teams is the research and

discovery aspect, which I would argue a bias to your

course because now my heavy focus is product.

But I still think that is one of

the most important, if not the most important

way that product teams can achieve success today.

You have to get with your customers, you have

to spend time with your users, and you have

to better understand where the opportunities are.

So refining that process and making that process more

efficient will ultimately make it more effective, which will

enable your team, as part of the next phase,

to move even faster in terms of success.

So I just wanted to share these trends with

you and that this is what I have continued

to see and I think it’s going to continue

to follow this pattern for the foreseeable future.