Originally published in June 2020 here

Consultants from top management consulting firms have been part of many teams I had the pleasure to work with when working with corporates. Almost always they are super nice, super smart, super hard working people and it is a pleasure to have them in the team. They will adapt to any new situation in record time and you can throw anything at them: they will get it done.

However sometimes they don’t work in your team but you - as a software development product person - are actually working under their leadership and this requires both sides to adapt and understand each other's way of working. This article tries to work out the 10 biggest differences between consulting and product teams, understand why these differences exist and recommend collaboration guidelines to get the best out of both worlds - both in terms of results and in terms of enjoying the experience to get there.

So why are working styles & team cultures so different? Both cultures evolved to fill different needs: In essence strategy consultants exist to advise top management on high value decisions - their job is to serve and help their clients. They may provide analysis, a concept, options and more with a typical team size of around 3-5 people. Their main output is predominantly an intellectual/conceptual concept often in the form of a PowerPoint presentation which helps their client make a more informed decision.

Product teams on the other hand exist to build a software product & make it successful. They work in a typical team size of 5-20 people and their main output is software code and a designed frontend in the form of a digital product.

Given these differences, it is also not really surprising that differences in working styles exist. So let’s go through the top 10 together - please keep in mind that i purposefully paint a black & white picture here. In reality of course there is way more nuance.

Difference 1: Types of profiles

Consulting teams

• Most people will go through the same ranks from Associate to MDP (Managing Director and Partner) - meaning that their key skills and tools they apply in their work are very similar/homogenous. While consultants may have studied different things, in the end everybody has acquired and is proficient in similar skills.
• Therefore an MDP is also an expert Associate and is used to going really deep into every topic if needed.

Product teams

• Everybody is different - meaning that people have learnt different and distinct crafts. In order to build a product you need engineers, designers, strategic designers, product managers and so on
• All roles are expert roles which cannot be fully learned in a few weeks so while there is some overlap in general you need a mix of those people in your product team to cover all your requirements to build a great product

Recommendations

• There is a much bigger information asymmetry in every product team - meaning that people do have expert knowledge and people need to trust each other. For example only engineers will know the time a certain feature will take. If now a product manager (or consultant) puts too much pressure on the engineering team they will likely just react by increasing their estimates to get more time in the next sprints. So high pressure may help you get a milestone done, but you will loose speed in the long run. Intrinsic motivation is needed - let’s be nice to each other :)
• This can be new/scary for consulting teams who are used to check everything themselves if needed and normally know exactly how long things take based on the years of experience they have on similar topics.

Difference 2: Priorities in life

Consulting teams

• Consulting companies are often designed with a very clear career model in mind. More or less every 2 years you will be “up or out” and the ultimate goal is to become MDP. In order to get promoted you need good ratings from your managers and in order to get elected MDP you need practically 100% approval of the other MDPs
• This system is a contributor to the fact that consultants typically work very long hours and consider finishing at 10pm during the week a good target which cannot always be achieved.
• Also you have limited choice where to work: there are only a few top consultancies in the world

Product teams

• Product people are typically less career driven but rather purpose driven. They want to build cool stuff. Therefore they are typically not that willing to spend long hours - especially on topics which they don’t consider super valuable.
• If they don’t like it anymore they will just move on since they have much more choice where to work: Thousands of great product companies exist in the world
• Product people also get paid less than consultants so naturally they expect more free time

Recommendations

• Teams need to be motivated differently: Product teams need to understand more “why” the certain goals need to be reached by when, and why reaching the goals is a good thing
• Product teams will be able to do bursts of overtime before an important release but will revolt if this becomes the default

Difference 3: Staffing

Consulting teams

• Becoming a consultant at a top firm is obviously hard and people earn top dollars because they are some of the smartest people in the room
• However once you are “in the club” you are actually expected to be able to parachute into a project and be up to speed in 1-2 days. In this sense especially Associates and Consultants are pretty interchangeable. High flexibility and the ability to learn fast is one of the key things you need to be good at as a consultant.

Product teams

• While it may be easier to become an PM, engineer or designer than a consultant, once you are working in such a position you are actually harder to exchange
• Typical product work requires deep knowledge of the topic AND product at hand so in order to get up to speed it will normally take over 2 weeks to become useful for a product team. Really deep understanding of the product is only reached after several months or even years

Recommendations

• Staffing should work differently for product teams: You need to keep the team more stable
• Adding more people in a product team may actually (temporarily) decrease the overall speed due to higher organisational complexity and the work required to get the newbies up to speed

Difference 4: Reaction to pressure

Consulting teams

• Consultants are like racehorses. If you put pressure on them they will run faster
• In a sense it's similar to a professional sports player - a really great sportsman is expected to excel under pressure. You are a champ if you win high stakes tournaments

Product teams

• Product people are sometimes a bit like a deer: If you put a spotlight on them they may stand still in the middle of the road and freeze
• They are a bit like an artist - if you put pressure on them they cannot be creative

Recommendations

• Product people need to be primarily encouraged to reach a goal, not put under pressure

Difference 5: Planning work

Consulting teams

• The work of consulting teams is typically hard to plan since they often need to be able to react quickly to client requests - within hours or minutes.
• Therefore often the answer to "found work" will be to just work harder/longer to be able to fulfil the request while still being able to finish the deliverables of the project. They will just sleep less and get it done.
• From my perspective this general necessity results in a culture where doing tough calls on priorities are just not that common as in product teams. Classic MDP joke: If you go to MDPs and ask them if they want A or B they will say “both” ;)

Product teams

• When a product team “finds” additional work, in 80% of the time the best answer is to reprioritise work or scope features differently. Work harder is often also involved but this can only be 20% of the answer. The reason for this is not laziness but feasibility: Every change on a product is much more effort than a change on a PPT. Most of the time you simply cannot pull an “All nighter” to get it done.
• Also building a product requires deep understanding of a topic and includes the complexity of managing several people and workflow steps. Therefore for software development the minimum sprint duration (=time where goals are not changed) should be 1-2 week for optimal productivity.

Recommendations

• The perceived unwillingness of Product teams to “just get it done” can be really frustrating for Consulting teams. All they hear is “no”. Instead of saying “no” the better discussion to have is about priorities and product teams should establish a roadmap where these trade-offs are clear and can be updated every sprint.
• The minimum sprint duration of 1 week should be observed for maximum productivity.

Difference 6: Customer vs. Client

Consulting teams

• Consultants typically have a long-term relationship with their clients - the whole business model is based on recurring revenue from that client and therefore they will do everything to keep the client happy
• In this sense: their client is their customer

Product teams

• Product teams may also be paid initially by a client or VC - but they will try to build a product for the eventual end user of that product
• Only when you get recurring revenue from this end user the product will be successful.

Recommendations

• Both teams are very customer driven - they just have different customers.
• Use this creative tension to keep the client happy while building a great product for the end user

Difference 7: Type of management experience

Consulting teams

• Most consultants grow up managing a team of 3-5 highly motivated people who are super easy to manage. They typically sit (at least before Corona) all in one team-room and therefore everybody knows anything all the time anyway. Principals / MDPs manage several of those 5-people-teams at once - but not very often bigger teams operationally
• In addition consultants have experience in (re-)designing organisations in really big corporations with 50k+ employees

Product teams

• Product people typically work in teams of 5-20 people which requires a different approach to management:It’s too big to just sit everybody in a room. It’s way too small to be compared with a corporate situation.
• People working in product teams are much harder to manage than Consultants - as we have seen above they need more purpose, context, empathy and sleep :)

Recommendations

• Consultant teams and product teams need different management styles.
• There is a reason it took people 20+ years to find a structure on how to build software well. Let’s use that experience. For example you typically need clearer roles & responsibilities (e.g. who is the Product Owner?) than in a consulting team since products are build in a more specialised way.

Difference 8: Decisions under uncertainty

Consulting teams

• The job of a consultant is to structure and lay out options so that somebody else can decide. If things are uncertain they will ask experts and / or the client and list the information they have found with a source. They very rarely need to make the final call themselves
• However at the same time they are very good in hypothesis driven thinking - so thinking through the impact of certain decisions in advance and laying out scenarios. They are also very used to making the call to focus on one hypothesis over the other.

Product teams

• Product people will often initially go into a “ideation mode” to lay out all options and then ideate again in a so-called “Double-Diamond” process.
• They will also try to minimise uncertainty by making ethno research and using other techniques. However at some point a Product team also needs to make a call under uncertainty - especially at the beginning when you don’t have usage data yet. This is actually very similar to the hypothesis driven thinking of a Consultant team

Recommendations

• Consulting teams sometimes get frustrated that product teams spend much more time ideating than a consultant team typically would. They should share their hypothesis with the Product managers who are probably more receptive for the push for an initial hypothesis than the designers. Also there is a reason the designers are using this approach: really great ideas can come out of it! As always there is an optimal balance and PMs are trained to find it.
• When it comes to making the call in which direction to start running let the PMs do their job to massage everybody in the same direction. If the call is perceived to be to be too "top down" the rest of the Product team may not be on board which will result in lower productivity. As we have learned product people need to be intrinsically motivated to get the best out of them
• Both PMs and consultants need to keep in mind that you will never be able to completely derisk any decision. See Henry Ford: “If i had asked what my customers want, they would have said faster horses”

Difference 9: Number of balls in the air

Consulting teams

• Consultants tend to get really happy if they can structure a complex problem and develop a framework which makes sense of the world
• They love having lots of “balls” in the air and add them to their framework to make it more useful

Product teams

• Product people know that the “devil is in the detail”: Whenever you start an actual implementation you will discover several layers of complexity under the hood
• Therefore product people are normally well advised to limit the numbers of “balls” in the air to have enough capacity to go deep and coordinate all the different people required to get it done

Recommendations

• Consulting teams should allow product teams to concentrate on a few balls at the time. It's great to have the (consultant) framework in the background but let them work through it step by step

Difference 10: Approach to reach high quality

Consulting teams

• Let's imagine you go into a 3-star restaurant. You can demand best service and best food for the price you are paying, and the waiter will do whatever he/she can to please you as you are also paying for the experience
• In this sense consultants want to always deliver high quality to their clients and have setup the whole process in a way that everything is being looked at by at least 4-6 eyes before the client sees it

Product teams

• Product people make decisions under uncertainty all the time (see above) - therefore being wrong happens and is mostly seen as an opportunity to learn and not as a failure
• Product people have even coined terms like “MVP” (Minimum Viable Product) or “Lean Startups” to celebrate the idea to launch imperfect products into the wild. Not because they don’t like quality, but because releasing early/fast is the only way to reduce uncertainty about what the customer really wants.
• You need to release fast to understand what high quality means

Recommendations

• You cannot build an MVP with a Consulting style quality approach. Product development is about rapid iteration & release and not about always delivering perfect quality
• In a way you need imperfection on your way to reach high quality in a product context

Summary

After looking at all the 10 discussed differences the short & simple answer is: Let everybody do what they do best in their own way.

The Consultants should allow the product team to establish a proper “product organization” within their team. They need to restrain themselves to directly interact with everybody in their “consulting ways” but rather work through CPO & CTO and let them run their product team how they want it. To say it in a positive way: You get a Single Point of Contact of an integrated product team and then don't have too worry so much about it - isn't that great? :) Do request a roadmap from the Product team and measure them on their output - but don’t try to “speed things up” by using the standard consulting best practices - some of the normal instincts wont work here as we have hopefully learned in the discussion of the differences above.

Product teams should use the roadmap to explain the trade-offs you have to make to get things done given the capacity of the team. Always ask the consultant colleagues “Is A more important than B?” instead of just saying “no” to everything. Repeat this process every sprint when you update your roadmap. Explain that you have to involve the whole team to do collaborative planning to get proper estimates and can only give indications on the spot - not the final planning. Consider to include consultants as PMs in your product organisation - they can normally do the job well and this will give the MDPs from the Consultant side lots of trust. But first and foremost: deliver on your roadmap: nothing builds trust better than results.

At the same time the Product people need to acknowledge that without the consulting team they will probably be completely lost dealing with big corporates. They will be frustrated by red tape, not understand company politics and documentation demands from the data security departments may appear as more work than building the actual product itself. There is a reason most product driven startups fail after they get bought by big corporates ;)

So let’s work together to achieve the best of both worlds when building products in a corporate context!

‍