Product managers need happy and productive team members. But coming up with ways of motivating them can be a difficult endeavor. As we have previously discussed, money could be an incentive for some but the effect is very often short-lived. 

What many employees really crave for is for their thoughts to be listened to and have the freedom to innovate and make a real difference to their organization and the world as a whole. 

If the company has already succeeded in aligning them towards a mission and purpose, the best next step is to ensure that their creativity is set free by providing them with a safe place to innovate.

This comes through creating intrapreneurs.

Intrapreneurship is the act of behaving like an entrepreneur but in a large company. This doesn’t mean that a large company can function as a startup but only that some parts of it can operate this way.

So how can you, as a product manager, help set this direction?

First, if you have successfully implemented the hypothesis bank, you are one step further into turning your team members into intrapreneurs. People contributing with their ideas gives them a sense of involvement and paves the way for an innovation culture.

Second, make sure everybody in your team understands the North Star Metric.  

Do you have it on the roadmap? Great. Now make sure you continuously convey it to everybody. Ensure that thoughts and actions gravitate around the NSM. This is especially important for employees that need a bit more guidance and direction than the rest. 

Assign projects, not tasks

As the title says, don’t assign tasks, assign projects instead and make people responsible for them. Building projects around motivated people and supporting and trusting them to get the job done is essential for any healthy organizational culture.

Once given, the project it’s not anymore your “thing”. It’s theirs. Let them proudly take ownership.

Teams usually discover tasks by doing real work.

For example, the project is about redesigning the checkout page to improve signups. The designer adds a coupon button on the desktop interface but then notices there’s no obvious place for it on the mobile version. So she has already discovered a new task, and that it to “test what is the best place for the coupon on the mobile version”.

Project ownership and a sense of freedom from discovering their own task change the employee thought process from continuously looking for direction to taking initiative and becoming creative.

Small teams

Once the roadmap is in place, we need to select people working on specific projects. I suggest dividing the work so that no more than three to five people are part of a team owning a project.

Very often we see incredibly talented individuals getting lost in big teams and no longer realizing the impact their work is having. This leads to a diminished sense of acknowledgment, motivation, and accountability that could have a negative domino effect on the company’s goals as a whole.

Remember the Amazon rule where the team should be small enough so that two pizzas are sufficient for feeding them? That is a brilliant example of a small team concept.

Small means flexibility. It also means that communication will flow nicely and that friction and clutter will be reduced.

Preparing the project brief

If the items above will set you on the right path to fostering autonomous teams, how you prepare and deliver the project brief will have an enormous impact on the way they work and provide value to the company.

When preparing the brief, your job is mostly to define the problem, provide an abstract sketch of the solution and set up some boundaries. Your team will have to take it from there. 

A good project brief aimed at delivering high outcomes and igniting the entrepreneurial spirit of the people should answer the following questions:

• How sure are we of this hypothesis?
• Why are we building this?
• What are we building?
• By when we should have it ready?
• How should we build it?
• What are the risks we might face?

Let’s discuss them in detail.

How sure are we of this hypothesis?

Before jumping into writing down the project brief, it is important to get the right confidence level depending on the estimated size of a project.

The rule of thumb is that projects that are big and with a high involved risk require a higher confidence level. Small and less risky projects can be fast-forwarded.

Acquiring the right confidence level for an unpredictable project can be a project in itself. Think about building a smoke test or a manually operated test. The team is still going to need a brief, resources, and some level of direction.

Also, keep in mind that at this stage we could walk away from the project. For whatever reason (like newly acquired data through a smoke test) we consider that the project doesn’t currently make sense anymore, we can disregard it completely or keep it for later. Overall you did get closer to a potentially viable option that it can be reignited after some time.

Why are we building this?

Build yourself a good habit and ask the “why” question as often as possible. This applies especially when writing down the brief of a project.

As discussed before, the raw answer should always be that “we are building for learning”. Learning is the ultimate goal. Again, we are validating a hypothesis just to be able to learn and proceed to the next step from which we will further learn.

But a detailed answer specific to a certain project should include a goal that by the time we finish the work and put it in front of users would serve as a success measuring tool.

If the goal is reached, it means that we have nailed it. If not, use what you have learned and iterate from there.

For projects aimed at increasing the confidence level of a hypothesis (like a human-operated test), the goal is self-implemented.

What are we building?

Again, when you define an idea you should frame it as a hypothesis demanding validation. Then think about the problem that needs to be solved and if it really matters for the user (you should assess that when working on the confidence level).

Finally, check how the hypothesis, problem, and goal are related to each other. This will explain to the team what are we building, for what problem and why.

The thought process should flow nicely:

“Our hypothesis is to build X because people have Y problem and the outcome will be an improvement of metric Z that will help boost our NSM.”

By when should it be ready?

When dealing with resources, the “budget” keyword is paramount. And while we are tempted to attribute “budget” mostly to finance, I would go one step further and apply it to time as well.

When we buy a product or a service, we don’t precisely pay with money. We pay with the time spent to earn that money. And if you think about it, time is a resource that incorporates an extended amount of other sub-resources. Time is money, effort, energy, deviation from standard routine and lost opportunities that could be more impactful to our goals.

Taking these two powerful words “time” and “budget” and putting them in the same context is clearly a powerful tool. It implies the fact that time is bounded, limited and somehow tabu. Asking for time extension is like asking for more money. Which is true. 

“Balance the budget”,”respect the budget” they keep saying, and they are right. Budgets should be respected and balanced.

Since time is the only resource that your team is never going to get back, I believe it should be a strong boundary set to a project. 

When doing the ICE framework assessment and picking up a certain hypothesis for validation, you should have already checked with your tech experts on the feasibility of the idea and dev time required depending on the size of the team. 

But we have already discussed how people are overly optimistic about time judgments. And how we should add at least one-third buffer to the overall budget. 

Taking all this into consideration is time for you to budget this properly (pun intended). 

Depending on the desired goals, you can define it to reflect how much you think validating this hypothesis is worth. Then ask your team to build the best possible solution given the time budget they have.

You might get pushed back by the perfectionists in your team claiming that the allocated time would not allow for the “best solution”.

The problem is that “best” or even “good” are relative concepts. Without a time budget, there is always something better that can be built. People might start working on something, and halfway there they come up with new ideas and ask for extensions. This can easily transform into a vicious cycle of new ideas and extensions that would eventually prove highly inefficient.

How should we build it?

Create a “skelution”. A skelution is a sketch of a solution with the right level of detail so that it doesn’t tell too much but neither too little.

Entrepreneurs are people who identify a problem and use their creativity in order to come up with ideas and ways of solving it. Your team of intrapreneurs should be encouraged to do the same. The trick is to provide the right level of direction so that their creativity is not limited but, at the same time, to ensure that the work will be in tone with the bigger picture and respecting certain boundaries. 

You essentially tell them how to get there without mentioning the transportation method. Or maybe that it only needs to have two wheels instead of four. 

Coming up with the skelution is more of an art than a science, one that product managers learn to properly do in time. It is also a skill that needs to be applied contextually. Some team members need more direction while others less. 

Depending on the complexity of the project, the skelution can be drawn in the form of a sketch or just written down in plain words. The former is preferred. Product managers without a design background shouldn’t have any problems drawing a simple sketch using one of the multiple sketch creating software out there, or even directly on the whiteboard. 

It is also important to note that in software development (and not only) projects usually commence with the designer work. Therefore the skelution is primarily addressed to her. Based on her outcomes the backend team will start rolling out their magic.

Also, try to hold back from giving your team any examples (especially from the competition) unless there is a compelling reason to do so.

In summary, working with skelutions and on the right level of direction not only ensures that your team moves at the right pace, but it also creates a fertile ground for innovation in later stages. 

What are the risks we might face?

“What can go wrong? And what if…?”

One reasonable manner to determine the risks of any project is to walk through the use case slowly and in detail. Ask yourself:

 “Where does the user start her journey, what’s happening on the way and where does the road end?”

Easing the pace can reveal certain pitfalls that we need to reanalyze. 

In addition, this might be a proper time to get more input from your extended team. 

There may be a technical assumption and you need to verify it with your lead engineer. 

You might assume the layouts fit together nicely but need to double-check it with your designer.

Your data scientist could provide substantial information on user behavior that contradicts some parts of your hypothesis. 

Your sales team can identify certain gaps that you would have never thought about.

Assess all the possible risks and address any major questions before the work initiates. Involving your team in de-risking the projects will also enforce the intrapreneurship culture of the company.

Write it up

At this stage, we should have already resolved all of the important concerns of our project. We know why we are doing what we are doing, how to measure success, what are we building, how, when, and what could go wrong.

Write it down and send it to the team in charge.

Example from Pillar:

• Project: Improve the sign-up process;
• Goal: Increase user conversion rates;
• Problem: Users require more trust in our service before committing;
• Hypothesis: Adding custom fields depending on the user’s initial demographic related aanswers (improve personalization) and including dynamic testimonials that match the answers (increased social proof) would boost trust in our service;
• Time budget: 1 week;
• Sketch:
• Limitations: The whole process shouldn’t take more than 3 minutes.