Building a new product team and introducing innovation in a services enterprise company requires a major culture shift. People want and fear change, so you have to be strategic, dedicated, patient and persistent about it. For many years I’ve been building teams in different environments and I put together a few suggestions on things to look out for and the reasoning behind it.

1. Learn about the environment you build your team in before you start

Job hunting internally and externally should be treated the same way. Over the years I had become more selective, and started interviewing employees within the company I am interested working with. The goal is to be a good fit both ways and it helps increase the chances. The reality is that there is no perfect job, company or person. But knowing about the faults in advance, can help you decide what you can live with and what you can’t, and if you can help improve and change it.

2. Make the time to research before you start

Great product managers are results driven and base decisions on facts. You want to be able to quantify and set goals straight from the start, and then argue decisions based on facts rather than opinions. Watch out for what information you are given that is based on an assumption or opinion vs fact. If you don’t have all the information you need, set your initial goals on finding it or put together a roadmap of how you get there.

Things to look out for: sales, revenue, expenses, budget, analytics, customers, platforms, infrastructure, frameworks, documentation, user tests and feedback, customer tests, customer feedback, etc. Doing it early can help shape the product or your road map.

3. Build a network

Investing in people is always a good idea and can help when you need support. You want to have allies in the organisation that will support your opinions and your vision. That will also give you leverage when the odds are against you.

4. Pick the right team members to fit the culture

Every organisation has it’s own unique culture and teams subculture. Bringing more people on board changes the dynamics and should be done carefully. Take your time with choosing the right people, and if it’s not working out, try to end it quickly. “Hire slow and fire fast”.

When recruiting, it’s a good idea to figure out what are the must have skills and qualities, and what you can compromise on. I’m a big believer in bringing smart people together and collaboratively solving problems. You want the person to fit both the team culture and also the extended organisation culture.
I suggest to go through a few stages of interviews with multiple team members and a technical test or task to confirm interest and double check it’s a good fit.

In an interview, I often like asking “explain a complicated concept to me that you know well like I’m a five year old”. It tests the interviewee’s communication and problem solving skills. I occasionally give 2 minutes to prepare if needed depending on the seniority.

5. Identify the ideal team skillset and fill in the gaps early

My diverse skillset often allows me to fill in gaps like development or design within my team. Previously working in startups it made a lot of sense for me to jump in and help, since it reduces headcount and cost. But in an enterprise it may not be necessary if the budget is larger and flexible. Knowing what skills are necessary for the team early can help with free the product manager to focus on their own responsibilities and get to coaching straight from the start.

6. Write a simple getting started guide

Putting together a basic getting started guide is really beneficial for new team members. They get up to speed quickly and avoid all the basic questions. They generally feel more welcomed and that there is a structure and process in place which makes them feel safer. The guide may include information about the team, product documentation, tools, training, how to’s etc.

Use a collaborative publishing tool like wiki or google docs and get the team to slowly add and improve it.

7. Get your agile process right

Every company has their own weird flavour of agile. It makes sense to tweak it according to what makes sense for your company or team. But you have to make sure that the value of the agile process is still there when you do change it. I generally like sprint plan on Monday, standups daily, and retrospect on Friday. You want to make sure that team members are comfortable managing their tasks and can build momentum.

I also like to include 1 on 1 meetings monthly to provide feedback both ways.

8. Be clear about responsibilities — leaders set the vision and the team executes

Understanding the responsibility of the leader and the team is really important in getting the team dynamics right. I believe the responsibility of a leader is to set the vision and for the team to execute. That helps build trust and allows the individuals within the team to optimise for best performance.

A leader is also responsible for looking after the team and creating the environment for the team to succeed. If the team is not functioning, it’s the leader’s responsibility to fix it and being present is really important.

When the team is working efficiently together, you can have many leaders in the team regardless of the roles and levels. To me that’s what flat hierarchy means; having equal say, making decisions together or letting others in the team lead and own a specific tasks and others follow. That means that a junior could be leading a senior in specific cases. It’s a good opportunity to practice humility, teach and learn. That also means that employees get to practice their leadership before becoming managers which means better culture in the long term.

9. Introduce and practice fail fast and make sure the team feels safe doing it

Most organisations will protect employees from making mistakes, and employees fear making mistakes with losing their jobs. It’s a big gap, and to reduce it, you can shift the emphasis to taking ownership and responsibility.

Failing fast basically means increasing the number of tests, which often there is no tests being done. For example sending a promotion to 100k users with a single subject vs split a/b test 4 different subjects.

It’s harder to measure and learn from things like problem solving, practicing soft skills, but it’s just as important and gets easier over time.

Collecting insights and sharing it with the team is an important part of the process and ensures continuity and avoiding repeating the same tests. There are insight management tools online or a simple shared document or spreadsheet would suffice.

10. Empower your team members to make decisions

Making decisions is a lot easier if there is a general guideline that aligns with the vision. For example:

Ask yourself the following questions: (not in a specific order)

• Is this a core feature or complimentary?
• How many of our customers must have it?
• Does it align with the product vision and mission?
• If the product evolves into something else, will it still be needed?
• Can you make it reusable for other products or teams?
• If it was your own money, would you invest on it?
• Have you done any research to support this decision?
• Have you found other products with similar features?
  I* s there any open source / frameworks we should use for it? Does it decrease / increase time?
• Can we test it to reduce impact? How many?
• Is the 80/20 approach sufficient for this feature? Do we have to perfect it or basic is enough?
• Is this feature so important to change the product to make it viable or lovable?

Then try to follow the spiral approach:

1. Scope the feature with best case and minimum case.
2. Plan for best case, and then work backwards to plan the minimum case. Then draw a line between to try to avoid having to rebuild, so we can slowly enrich and get to the best case.

It’s very likely that by the time we are ready to enrich this feature, priorities may change and the product may evolve, but it helps reduce the possibility of having to do complicated upgrades and rebuilds.

Size of impact for making decisions can be defined and started with something small, and as you build more trust it can grow. For example, anything that can be fixed with 1 day of work or $100 is fine, and then grow it to a week / $1,000 etc.

I generally like getting advice and try to include others with what I am doing to get their opinions and feedback. It usually only takes a few minutes and can give me good perspective or see if I missed anything. I share what I am doing, my thoughts and what I plan to do, keep it concise and to the point, and get their opinion. Most of the time there may not be feedback at all, but occasionally there could be something I didn’t consider or see and that could be very valuable. It gives me the opportunity to lead by example and to demonstrate transparency with the team. I encourage the team to do the same when they are problem solving or making decisions.

11. Define how to measure performance within the team and make everyone aware

Agile methodology recommends to measure the team productivity and velocity based on the accumulated team points every week. That increases collaboration and means helping others contributes to the overall result of the team. That means not every moment will be tracked.

With a brand new product it sometimes doesn’t give the best reflection of individual performance though and velocity could be critical. There is value at measuring lines of code written, design pages delivered etc. But I think it’s important to keep these numbers within the team, and only communicating to stakeholders the overall team performance. You can handle individual performance internally, be transparent about it and try to work it out collaboratively within the team. The team can then help figure out how to accelerate.

It’s really important that all members of the team know about this, including new members who just join.
For conclusion, it’s not easy putting together a new team and very difficult to get it right from the start. I hope the suggestions above make it a bit easier for you.

**
Please share this with all your friends and hit that upvote button below to spread it around even more. Also I’d love to hear if you have any tips or experiences you would like to share in the comments section!

---