Intro Music
Welcome back guys.
My name is George Brooks and I'm one of the founders here at Crema.
We are a digital product agency.
We're working with companies all over the country and world to build product teams.
We design, develop, and help product manage solutions from ideation all the way through to
growth.
Today what we're going to talk about is lessons that we've learned growing product teams here at
Crema and with our clients.
So there are a number of things that we've done accidentally right and some things that we
probably haven't done really well or that we've learned don't work as well.
And so I want you guys to avoid those pitfalls.
And so we're going to give you a few tips and tricks to figure out how to build your product
teams or work with people that are building product teams.
Stay tuned for sure all the way to the end because there is one piece of advice that I wish we would
have known sooner.
And that's one of the biggest reasons that I think a lot of product teams fail.
So stay tuned all the way through.
First off let's just put it in your head now,
You are in the business of people.
You just happen to be building apps.
We try to over, you know, amplify technology in the world that we live in either because we're
just assuming it's going to replace our jobs or we think it's gonna make our life easier and in some
ways some of those things might be true.
But really what we want to be focused in on is technology doesn't happen without people.
And so you really have to be focused on your teams.
So that's why we want to focus in and why we do focus into product teams.
So first off don't get too stuck on the technology.
Think about your people. You're in the business of people.
One of the first things that we're seeing is that across the industry as a whole there's a big
emphasis on diversity.
Diversity can be a lot of different things but for us it really
first and foremost comes down to cross discipline teams. Working with people that are in different
roles under one single unit or one vision of the product that they're working to build.
There is the diversity of cross discipline teams, but there's also the diversity of backgrounds and
perspectives and even cultural diversity as you're building out your product teams.
Avoid having a team that everyone looks the same.
Having males and females and having different color skin on your teams and having different
backgrounds even different ethnicities and languages really add to the value of people
bringing different perspectives into what is gonna make the product great.
Because you might have somebody that says. "That's a really great idea. If everyone is this and
this."
But as soon as you introduce some diversity into the group you start looking at things through a
different angle and can really see things that maybe you wouldn't have been able to see on your
own if anybody looked the same.
Keep teams small and keep sprints small. Companies have grown massively in the last few years.
Startups or especially technology companies are just taking off and they're really starting to
build massive teams.
But the companies that we're seeing be most successful including crema here is when they
create focused teams that stay small.
So for us, most of our teams are no more than three to five people and usually it's more than
five person mark.
That doesn't mean that those all five people are 100 percent dedicated to one project.
You might have them floating between jobs but the reality is that you keep that team small so that
you don't get this large kind of "group think."
Instead you can make decisions, you can move quickly, and you don't have to get this cross buy
in that can that can really weigh down the velocity of your project.
And then keeping sprints small.
So instead of casting a vision for a roadmap for what you want to do over the next six months, a
year, two years, three years, that's fine if you want to project what you think it might be.
Focus more on what you're going to have to do in the next week or two so keep your team small and
keep your sprint small.
Culture.
I think one other factor when you're building your product teams and especially when you start to
have diverse views is that you really have to be careful to make sure that their culture stays
healthy as you create each new team.
You may find that your first team, kind of the founding team or the the champion team inside your
organization is tight knit because you're all bought into the vision.
But as you start to build new teams and each of the many components are focused areas for your
your solution or of your business, it's easy to let that slip and just think, "Well you know, all
I need is to represent the different roles and culture will probably come because everybody's
gonna act like we did."
And it's just not true.
So you have to train people how to really be sure that they work well together. That comes with
diverse backgrounds and perspectives so that innately bring some tension.
So one of the things that we look for and we talk a lot about is a term we call "Humble Confidence."
And so we really suggest that if you're looking to build your teams, look for teams that can stay
confident that they know how to build the best solutions and that they have great ideas, but
they're humble enough to know that they can take input from other people and that the team can get
better over time.
If you have that one person that's not fitting or is causing strain in the team do something about
it quickly.
So that may mean you just have a conversation. They may not even realize they're acting like
that.
So address that concern.
We have had situations and that's one of our lessons learned in the past where we had someone
on the team that wasn't a perfect fit.
It's not that they were not great at their job, they were very intelligent people, but they
weren't a good cultural fit to know how to work well with this diverse team. And what it ended up
doing is ended up dragging the team down and just created this weight, this oppression.
But it wasn't until that person was removed or was recognized as this being a problem and improved
and as soon as that happened it was amazing to see the weight that was lifted off the product team
and how much faster they moved and how much more efficient they became and how much better of a
product they created.
So this is something that maybe it doesn't have to be a rule but just something we found to be
helpful. Maybe consider changing up your teams every once in a while.
I think that over a period of time people get kind of stagnant.
I don't want to say bored, but they can get kind of tunnel visioned into really being comfortable
with the people they're around and the idea that they're working on.
So we don't have a process that's like fixed in place yet, but we have found that when our teams
were forced to change up for some reason whether that was because, you know, somebody left the
organization or a new team member came on or we had a capacity issue so we had to shuffle people
around for the most part, we actually found that there was more gain out of that change than there
was loss.
I think people are really scared that when you're going to change up the team there won't be this
knowledge background of what they've all been doing for the last year and six month or two years
whatever that is and that it's going to take them too much time and costs to get brought up to
speed.
What we actually found is it brought fresh perspective.
You start to see things that maybe you didn't see before because everybody was just kind of on the
same wavelength and things were happening in the same way over and over and over again.
Consider some type of rotation or some type of change out of resources that are working on one
particular problem or if you can bring something somebody new into the kind of mix up the kind of
daily grind of it so that you don't get stuck and not realize that you need to keep innovating you
need to keep keep pivoting or kind of refining the direction that you're going in your product your
solution or on your teams.
And then one of the last things I'll say is look at ways to give your team members and these cross
discipline roles a way to be better at their craft outside of this particular project.
So that may mean sending them to a conference or it might mean giving them time to continue to
train. Or for us at Crema, what we do is we have craft teams and then we have product teams or
project teams. And what that basically means is that on our project team you are working with
people that oftentimes are not the same role as you.
Because again, that diverse team is moving the product forward.
But what you lose is maybe the context of, "How are other people designing with Sketch today or
with Invision or Studio?"
"How are other people writing javascript right now?"
What are best practices in my trade or my craft as we call it.
What we do here at Crema ( and actually I think is something that kind of organically happened,
the teams just started to do it and now we're kind of naming it and seeing the value in doing it
more) is giving our craft teams or the trade teams a space and a time to meet and grow and be better
together.
So for us that looks like we have Dev Chats that happens I think every two weeks. Designer Chats.
You have the product strategists have Strat Chats.
We have Product Management Improvement. (Their name is a little bit longer because product
managers like that long terms for things. That's where product management meetup).
Give space for the people that don't maybe day to day get to spend time together. Give them space
where they can go off and actually meet with other people that do the same thing they do and they can
learn and grow and get better at that craft together.
It's a way to make sure that your product team again doesn't become stagnant in the way that they
do things today.
So I said that I would give you the one kind of biggest lesson learned for us.
All these things that I've shared so far have been things that we've kind of either accidentally fell
into or we did it wrong in some way and so it was we realized that people had been stuck on the same
project for too long and while they were doing good work they just you could tell they were just
feeling a little stale.
So we had to kind of constantly ask like "How can we get them out and help them to do better?"
And I think that kind of leads to the One Point of Failure.
The single single point of failure in any team meaning "Siloed." Anybody that's completely siloed
kills a product team.
This naturally can happen because of personality.
It's just that a person might be a little bit more reserved or introverted I guess is one way to say
it.
And so they pull back away from maybe being collaborative with the rest the team. It's not a
bad thing, but what it leads to is that this person starts making decisions on their own.
They start maybe running in a different direction and they miss alignment with the vision or the
purpose of the project or the solution or the company.
And so I think one of the big things is keep your eyes open.
Do the lean kind of methodology of watching for inefficiencies and look for anyone that might
start to become "siloed."
Someone who's just not getting up from their desk very often or someone who's not engaging in the
meeting.
See what you can do to pull information out of that person, to invite them into the collaboration
of the team. Look for ways to do silent activities.
So whether that's when you do brainstorming instead of having it being a vocal challenge of
who speaks the most and so the loudest voice always wins.
Instead to exercises where you put sticky notes up on the wall, and think about how you can vote.
And so they give him a voice by allowing them to write things down and then everybody votes rather
than "who did the best pitch for an idea vocally."
If you have the budget and the capacity to do this on your teams, think about how you can pair up
programmers. Pair programming has been the thing that's been around for a long time, which is to
say you both sit down and look at the same set of code.
One person writes, one other person kind of like reviews and asks questions about why are they
writing the code that way, and then you switch places.
The final result of the code is a better quality product.
Even though you think, "Well that's going to double up on time", it actually creates more
efficiencies so that people aren't spinning their wheels.
They're not getting stuck and they can move forward faster.
Traditionally it was with programming but there's no reason to say it couldn't actually work with
other roles as well.
Same thing with product management and strategy.
So they oftentimes are going, "Well how are we going to run this next meeting?" Or, "How are we
going to put together this plan or this roadmap for this particular project so we can communicate
it with the stakeholders, so that we can communicate it with our bosses and then that we
can share with the team?"
I think that by nature of having two minds thinking about how that might be done really keeps
people from getting siloed into
"there's only one person has all the knowledge".
And that's what you want to avoid if somebody got hit by a bus, God forbid, on one of your projects,
that not all the knowledge would be lost and left with that one person.
You may not have that luxury.
It may be that your team is so early and so small that you don't have enough bodies to do that.
But I think as quickly as possible looking for those single points of failure, those single
points that if something were to go wrong it would all fall back into that one person and that
bottleneck, remove that. Start getting cross discipline collaboration so that you get a better
result.
That's the number one thing I would say is remove "silos", look for ways that you can collaborate
with other people, and I think you're product teams are definitely going to be better for it.
So these are just a few tips and tricks, a few lessons learned from a company that builds product
teams. We have several product teams here inside of Crema.
We've been doing this for the last 10 years, building product teams, and we're helping our
clients build their own product teams.
And so if you're thinking about building a cross disciplined, small product team that can move fast
and build great solutions,
maybe these are few tips and tricks for you.
Thank you guys as always for watching us today, for subscribing to our channel.
Make sure to subscribe and then turn on the bell.
I think that allows you to get all the notifications. Like us if you can as well on
YouTube.
This year we're really going to be dialing up our content.
We're really going to be pushing out videos and podcast and blog posts and material that hopefully
is useful for you.
If there's a question that you have or there's something that you're kind of struggling with as
you're building your product teams as you're building your products let us know.
Drop us a comment below about maybe what are some of the lessons you've learned as you've been
trying to build your product team.
Until next time.
Thank you guys for watching.
See you later.