This is how you build product
that people pay
you for, trip over themselves
to pay you for it,
without breaking the bank.
See, I've been building
software companies now
for 20 years.
I buy software companies.
I coach some of the world's
top CEOs,
and I've learned over the years
spending tens of millions of dollars
on engineering teams, product managers,
you know, all the tooling, the fancy
Kanban boards, project management,
you know, simulation
software, all of that.
It really comes down to these
five core principles
that if you implement
into your product process,
will help you build
innovation from insights
you learn from your customers
that will continue
to keep you competitive.
If you don't listen to this,
I know where you're going to end up.
Failing, because you won't have product
market fit.
I'm not even being dramatic.
You literally
maybe have some traction today
and then you're going to hit a ceiling
where there's more people
flying out the door
than you're able to bring in
and you're going to get frustrated
and you're going to give up.
And you’re gonna decide to either
shut it down or sell it for pennies.
This is how we do it.
Number one is define your product vision.
See a lot of founders,
maybe this is you or maybe you’re
a product manager
and you work with a CEO founder is
they have the vision,
but it's up in their head.
Okay.
My rule when I coach CEOs is
you need to communicate
where you want to be in 18 months.
Clearly, we're talking
like high level roadmap
so that the rest of the team
can make decisions that's aligned
with where you want to go.
Your vision, see if you've got a team,
even if it's six people,
like every day, they wake up
to make the product better,
to fix bugs, to
talk to customers,
and if you don't give them any direction,
then essentially you're hoping
that they see what you've never put out
visually
and execute against that.
That's why a lot of CEOs get frustrated
when their team make decisions,
and you're like, why did you do that?
You didn't define your product vision.
You didn't sit down
and actually describe,
this is the problem
that we're going to solve.
This is the customer
segment we're solving it for.
Here's our unique perspective
on how we're going to solve it,
and we're going to get everybody
aligned with this, meaning
every person in the company
is going to be pulling on the rope
in the same direction,
because if everybody's
pulling on the rope but they're pulling
in different directions,
guess what?
You make no movement
and very few companies
have a detailed definition
of their product vision
that they can use
continuously every week
in their product meetings
to let everybody know, hey,
remember, guys, we're going over here
and this is the problem solving
and this is our unique
perspective on the problem.
And these are the customers
we want to serve.
And any time the sales team
brings in people
that don't look like
those customers can we
can we ask them to stop?
And any time the marketing team
puts together marketing program
that attracts people
just because they get cheap leads,
but it doesn't get our best fit
customers, our ready to pay customers.
We ask them to stop.
All of this will allow you
to just get better,
leaner and faster
if you have a clearly defined
product vision.
Number two is create a roadmap.
See, some of you guys have maybe
never built software before.
It's your first time.
Maybe you've tried it in the past.
And you know, a lot of entrepreneurs
have this like Steve Jobs complex.
They're like,
I know what the customer wants
and they're wrong.
And if they if I listened to them,
I would just build a faster horse.
All, all this craziness.
A product
roadmap is very simple.
It's over the next short
term, typically six months,
maybe nine months.
You can tell your team
this is our priority.
Most importantly,
it tells your customers
what you're going to build
and what sequence, right?
My favorite thing to do
is actually ask customers for feedback
on kind of product feature enhancement
and then map that
feedback to the thing
I'm going to go build that
when I launch it because it's part
of the roadmap and everybody knows.
I then tell the customers
it was their idea.
Like sneaky, deaky trick
that could transform
the way you create raving fans.
You can't do that
if you don't have a product roadmap.
It’s different than a vision.
A roadmap is shorter
and it just let’s everybody know
this is what we're focusing on right now.
This is what we're going to focus
on next.
All your crazy ideas,
dump them into this
category of stuff.
And then every time we sit down to talk
about what we're going to work on next,
we can pull from there
to figure it out, prioritize it,
have a different process for it.
But a roadmap is a critical tool
that the best software
companies out there know how to manage
and communicate
to the rest of their team.
Number three,
create cross-functional teams.
See most companies that struggle
with really great product.
It's because they have an engineer that's
maybe in some other part of the world
and they're writing code.
And every once in a while
they throw stuff over the fence
and then you're like, okay,
now we got to test it
and we play with it.
We find all the bugs and then we like
send it back over the fence
and hopefully they fix it.
My philosophy
is to create pod structures,
and a pod structure is very cool
because it allows a group of people
to have everybody
they need to actually ship
working code,
see if you have like, oh, well,
this is a person that does the
the customer stories
and then that goes to a designer
and then that goes to an engineer
and then the engineer needs to talk
to their CTO to figure out like,
how does this get built
into our infrastructure?
That's where the breakage happens, right?
Whereas most of the best
software companies in the world,
the Facebooks, the Googles, the Amazon,
they use a pod structure.
Scrum talks about this, Agile
development talks about this,
where they can talk
to the customer directly,
take that feedback,
put together a product spec,
build it in-house,
be responsible for it.
My favorite examples of this
is HubSpot, where they would do,
I don't know what they called it,
but essentially show and tell.
So every two weeks
they would invite all the different pods
to show their work.
Now here was the criteria.
You couldn't show
unless it was actually in staging.
Couldn't have been clickable prototypes.
It can't be ideas.
If you want to demo on these show
and tell days,
you have to have working product
in staging
ready to go that everybody's like,
that’s amazing.
Ship it to production, right?
And just allowing this
process of continuously
upgrading and refining
so there's no bottlenecks.
I mean, most people don't know
this, but companies
like Shopify, Facebook and many others
ship to production
hundreds of times per day.
They've built their infrastructure
where if somebody has an idea
and they have the time in that day,
they can literally write
the code, change the thing,
submit it, it gets approved,
ship to production.
There's no no release schedule.
There's no like,
oh, this is our quarterly release.
If there is a bug,
they fix it, it's gone.
And the only way to do that is
if you have cross-functional teams.
Number four is you've got to monitor
progress and metrics.
Okay.
So at the end of the day, it's
not about lines of code that matter.
It's about did
the customer receive more value,
did the code base
get more stable?
Did our company achieve
their KPIs
or metrics we set out for?
You know, at the end of the day,
business is very simple.
How many customers come in?
How much do they pay us,
how many people stick around.
Very simple.
I know some of you guys are like,
oh yeah, well,
I measure this metric and this metric
and this metric.
It's like super advanced and nerdy stuff,
which I love.
But I also know that
at the simplest form,
if we can just instrument
those different data
points and say,
how many customers did
we get in the last month?
Did they activate, did they pay us,
did they stick around?
And then as you deploy
new features, see your
for your product features
should only be created
if they solve a problem,
if they improve one of those metrics,
you know,
a lot of people have good ideas,
but when you say, well,
how is this going to help the business?
And they're like,
well, it'll make our customers happy.
Okay, is it going to keep more customers
that are canceling?
Well, no, but it’s
going to make the ones
that are staying more happy.
Okay, well we've got 8, 9,
10% of the people every month leaving.
Could we start
with fixing those problems?
Could we pull the report,
what I call the customer
cancellation survey
and actually reverse engineer
what our top customers
that we would have liked to have kept,
why are they leaving and fixing
those holes first?
Too often people confuse
activity with progress.
To me, the way we avoid this is
we instrument our code base.
Everybody monitors those KPIs
that are important to us, including
speed and performance.
There's nothing worse
than releasing new software.
I remember one time our team released
this big search engine change
and it's like all
these advanced search features
and they were so pumped.
And then when I tested it out,
it was three times slower.
It doesn't matter
how cool your search is,
if it slows down the whole thing.
Customers don't care about that.
Jeff Bezos says it best.
He goes, look,
all I know in the future is our customers
will always want cheaper prices
delivered faster.
Think about that.
Cheaper prices, delivered faster.
So if your thing makes the site faster,
if it makes it
we have more product inventory.
If it makes the price cheaper,
if it makes it faster to get to somebody,
those are all really good things
you should focus on.
So monitor progress
and the KPIs and metrics
and that's how we create the baseline
for everybody else
to make the product better.
Number five is iterate
and improve.
See, when you get into larger
engineering teams, you will discover
that many of them have
this thing called DevOps.
And DevOps
is a department
that allows the engineers
to request ways
that the DevOps team
can make the writing of the
software easier, better,
just faster for them
to develop new features.
And one of my favorite examples
is, is this feature
that Facebook has called Gatekeeper.
And what Gatekeeper does,
it allows you to deploy new features,
but to focus on different demographics.
So if I wanted to test
some new, let's say I want to change
the color of the
the like button,
I can actually change it
for everybody in Canada
or even just 10,000
of our customers in Canada.
And it gate keeps it to just them
so that I can split, test
and test that change
versus control.
See, it's
hard to iterate
if you don't create baselines.
You know, if you're Google, I don't know
if you know this, but YouTube,
which is owned by Google,
their home page,
they have some customers
that are part of a control group.
That they’ve never seen
an ad on their YouTube videos
and they're not paying for YouTube
Red or advanced or whatever it is.
They literally say, okay, well,
we have all these different experiments
running for us to feed back
the learnings to the product
teams, to the product managers,
so that they can decide
what's the best thing to move forward.
Right.
To often,
you know,
people are in meetings
and product meetings.
It's called the HIPPO, the highest
income
person's opinion.
That's the most important.
It's like, who should we listen to?
Listen to the HIPPO.
What’s a..?
Highest income person's opinion.
The person who gets paid the most,
you know,
it's the product manager is the CEO.
But my philosophy
is listen to the customers.
I actually at a certain point,
the product is yours.
You have an opinion,
you have a philosophy,
you have a point of view.
It's opinionated software,
but as soon as you put it out
to the world, then all of a sudden
it becomes theirs
and you have to start working backwards
from the customer.
So being able
to move faster
by creating tooling
that allows you to split test to create
gatekeeping software, to
launch new features
to a specific audience,
to learn, to then
— I even had a friend once
he built a new tab in the software,
and when you click the tab,
it was a survey.
It wasn't the feature, nothing was built.
It literally asked the person,
what did you expect to see
when you click this tab?
Isn't that cool?
Like you don't even have to like,
know what to build,
just ask your customers.
Then he took all that feedback,
looked at their answers and said,
oh geez, I didn't think of that.
We should build this pivot table
concept for reporting.
Perfect.
Build it into the product.
That's how we improve our product.
To wrap it all up,
I want to share this with you.
This is a guy named Marc Newson.
He's friends with Johnny Ive from Apple.
I heard about him because he was rumored
to work on the Apple Watch.
Okay.
This watch right here,
why I have
this is
because this is his design journal.
There was only a handful
of these ever sold.
This thing is incredibly valuable.
And I bought it because,
and this is my invitation for you
is, become
a student of design.
Become a student of
product, become a student of
emotional
response to objects.
Marc Newson not only designed,
you know the lounge chair
to cars, to
Louis Vuitton bags
to buildings, to Apple Watches.
He is somebody that I'm
incredibly inspired from.
And for three or four years
I went down the rabbit hole of just
what does it mean to be
a great product designer?
How do we have product vision,
how do we create roadmaps?
How do we create cross-functional teams
to design some of the stuff
that he covers in this book?
That's my invitation for you.
Don't be just good at it.
Decide to be a master at it.
Go all in.
Surround yourself
with people like Marc Newson
and other world
class designers to be inspired
about how they think.
Because it's one thing to
to build software,
but it's another thing to build something
so great that other people copy
you for.
And I think that's
the ultimate expression of,
you know, appreciation is
do you see other people in your industry
steal or inspired
by some of your interaction designs
or your workflows?
That's that's
what I always strive
to think about
when I'm designing products.
So that's my invitation for you.
And as per usual, I want to challenge you
to live a bigger life
and a bigger business.
And I’ll see you next Monday.