The problem with digital transformation initiatives in the eyes of a Product Manager
Does your organization understand the difference between Product Management and Project Management?
To build a successful software product, engineering alone is not enough. Only if combined together with Product Management and Product Design you will have all the skills it takes to become a great product team that delivers successful products.
There is often confusion about what a product team does or should do. So, let’s take a few steps back and start with the basics:
There is a clear differentiation to be made between:
- Project Teams
- Product Teams
What is a Project Team?
In bigger corporations, “Project Teams” consist of a project lead, designers, and engineers. Their main function is to design and build features that have been passed down in a waterfall structure. They come as requirements from stakeholders and sponsors. You can tell because everything is driven by a roadmap with a set of features and deadlines that higher-ups hope for and expect to be shipped as soon as possible.
In such a model there is usually no room for user research. Rather, the designer does some design, some usability testing, and then the engineers start to code and deliver.
In such a model, there is no product management — but only project management. In this scenario, the project lead carries the role of a “Project Manager.”
What are the challenges for a “Project Team”?
From a design and engineering perspective
In such a model where designers are supposed to build just features, it is very hard to attract good design talent. Good designers know that this process is not what they trained for. They are overqualified, to simply apply the patterns that a company has, apply the style guidelines, and build high-fidelity wireframes.
The same is true for engineers. They are only there to implement and not to invent.
Thus, project teams and companies that work this way have a hard time to unleash the actual power of design or product
Now, what is a “Product Team” on the other hand?
A product team looks almost the same again. Here, they have a “Product Manager”, designers, and engineers, but now they are really focused on the product and doing design.
In this case, instead of being given a roadmap, the product team is given problems to solve. These can be customer problems or business problems, but they are problems.
These are conceptual challenges, for example, reducing customer churn, gain new users, hitting new sales targets, making a product successful in a new country.
In that model, a “Product Manager” needs to make sure that the solution being built is a product that a customer would actually use or buy (valuable) and that works for the different dimensions of their business (viable).
What does that mean for the designers and engineers in this case?
For designers and engineers:
In such a model, the product manager needs designers and engineers as partners, because now you are not sketching out features, but rather come up with a solution that works.
In this case, the designers and engineers need to support the product manager to understand all the parameters and constraints to build a successful solution. This can only be achieved through a longer “Discovery phase” (user research/prototyping/testing).
What this means, is that most of the concepts you propose, will end up not being implemented, but your learning curve is significant. The point is a conceptual one — are you figuring out what works and what users want, before you ask your engineers to build it, “QA”-it, and deploy it?
“Discovery” doesn’t come at the expense of “Delivery.” In fact, “Discovery” can speed up “Delivery”, as the product validation has been done before the “Delivery” is happening. This way you speed up the entire execution process and save A LOT of money on the way.
How can you transform your “Project Team” into a “Product Team”?
This is the main question every company should ask themselves currently carrying out Digital Transformation Initiatives. In Switzerland these initiatives are very common at banks and insurances.
Most of these initiatives go nowhere fast enough because there is a general lack of understanding that the digital transformation entails an underlying transformation of their organizational and operational structure.
This is actually the biggest problem they need to solve. It is much harder than giving people new titles and check a box. People need to be trained for this job and embrace this way of thinking.
What does this mean for the “Project Team”?
Step 1: Promote change
The leader of this team needs to give the team a chance and also take responsibility to promote a new way of working within the company. He needs to push the boundaries to convince the executive level of this structural/operational change so that the product team receives the green light.
Step 2: Step up your skill set
The “Project Team” needs to step up to the qualitative level of a “Product Team”. This means the Product Manager, the Designers, and Engineers need to take on more responsibilities.
(This should not come as a big surprise)
What they definitely need to bring into the team:
- Understanding about the customers, how they make their decisions
- Understanding the data that is being generated
- Understanding business constraints, stakeholder concerns
- Keep up to date with industry trends and competition
- Knowledge on how to conducting “User Research” (qualitative and quantitative).
- Gain a deeper understanding of a companies software landscape and deliver good “Service Design.”
- Be playful and structured enough to design consistent interactions (“Interaction Design”)
- Know how to build up a scalable design framework (Visual Design)
- The skill to invent, not just execute
They may need training, mentoring, and coaching but they will eventually get there. It’s only to their advantage as they will have a steep learning curve and it will not only reflect on their skills but also on their salary.
Step 3: Encourage inclusion
As a next step, the leaders are required to give the right instructions. It shouldn’t be: “Deliver this feature,” but rather “give the team the necessary context.”
- Product Vision (3–5 years)
- Product Principles
- Product Objectives
- Product Strategy
This is what OKR’s (Objectives & Key Results) are for. They are here to tell the team what to do. Only based on this, requirements engineering is possible.
People in the industry often ask for a recipe for success — “the silver bullet.” From our experience, there is no silver bullet. Only a good operational set up.
This means that the person driving the initiative needs to understand that product management, product design, and engineering all need to have a seat and equal say at the table and work cross-functionally -not in silos.
Since they are the ones building the product, they should also be involved from the start.
To find out more on how to measure the success of your product team and the product they are building, please read about our new blog post here: