CLE MENTINE VIOUX
After working in a firm that struggled to turn great ideas into a profitable business, its head of product shares findings based on her experience
After working in a firm that struggled to turn great ideas into a profitable business, its head of product shares findings based on her experience.
When I started as a product manager, the position was so new that many firms had little idea over the function of such a role. In the past ten years, however, this position has been explained, theorised and refined in numerous books. There’s no shortage of detailed methods that you can apply when launching a new product.
Handily, it’s even possible to translate it into five “easy” steps: know your customer, experiment, evaluate, build and then assess. In other words, the product manager takes the original idea and turns it into a real, profitable product for the business.
That’s the theory, anyway. When I started as a product manager in a decade-old company in transition, I often found myself quite helpless. Despite years of experience, and having scoured many books on product development, I couldn’t apply any of the processes and advice suggested. It felt that my situation was completely disconnected from the lean world of product development.
I went to meet-ups and heard other product managers tell amazing stories on how they increase they profitability with A/B testing, how they use detailed analytics to understand what their customers are doing, and how to improve the user experience. I heard how they define clear objectives and key results (OKRs) and form their teams around them. Then I came back to work and had to face a different reality.
Success blockers
So if everything sounds so right in meetings, what was going wrong? First was the company culture. Too often people were waiting to be told what to do, which is a big barrier to creating the right environment for success.
Second, there wasn’t a clear vision of where the company was heading. As a result, the various departments weren’t aligned – the dev team was completely disconnected from sales, for example. There was no will to join efforts towards a common goal.
Recruitment, too, was an issue. The company didn’t recruit people with the skills necessary for growth, nor the mindset to change things. Instead, it focused on short-term needs. Don’t misunderstand: the company did innovate and experiment. But that lack of vision resulted in a multitude of offerings and products, instead of incrementing and refining the current offering to best meet the needs of our customers.
For a young company, having too many products isn’t a recipe for success. It creates excessive noise and is expensive to maintain. It blocks teams from creating expertise in one area. Instead of solving one problem well and moving on to the next, the strategy was to throw all these potential solutions at the world and see what happened. Nothing good came of it. Where there was learning, it was impossible to follow through.
This is the basic concept behind A/B testing: change one thing at a time. Let’s say you add a new feature to your product and decide to reduce the sale price at the same time. It would be impossible to determine whether the resulting sales increase was a result of one or the other.
As a product manager it was also hard to focus on learning and value, since most of the time the tech team was busy developing features that were requested by existing customers. They were driving the roadmap, leaving no resources for innovation. If you’re not confident that what you’re building solves your customers’ problems, you let them decide what to do next.
Finally, due to a lack of long-term vision and focus, the platform wasn’t developed with flexibility in mind. So the technology didn’t allow easy iterations and was quickly outdated.
All these issues were blocking the company from putting processes in place that would allow for growth and expansion.
Lessons learned
So how do you transform an existing business to create the right framework for lean product development? Before being able to look at the future and begin experimenting, there’s clean-up work to do. Here are a few things I learned from this experience, plus five key takeaways for anyone starting a new job in a legacy business.
“Having too many products isn’t a recipe for success: it creates excessive noise and is expensive to maintain”
1. Slim down and get rid of old habits
Humans are creatures of habit. When a company has been around for a long
time, it’s hard to take a step back and question the way of doing things. As a new starter, it’s legitimate to question everything. Use your fresh eyes to be realistic and honest about any issues the company has. All explanations starting with ”we’ve always done it this way” should trigger an alarm.
Question the processes but also the product. Identify the features necessary to deliver the core value of the product and scrap everything you don’t need anymore. Assess what’s left, whether it’s front-end or back-end.
2. Get the right people
After assessing existing skills in the team, identify the gaps – but mostly get support from the best talents in the team.
When some essential skills for growth are missing, you must quickly decide between training existing employees or bringing in new expertise. If the team is resistant to change, it will take three times longer to put new processes in place. You don’t always have that much time, and this will drain much of your energy.
Often, though, this decision is pushed back because of the fear of losing employees’ knowledge. When you work in the same market for years, and on the same product too, you accumulate knowledge that you believe will be essential for your business to survive. The truth is, retaining a team for the sake of knowledge is wrong. There’s very little information that can’t be recovered or replaced in some way or another.
Letting go is difficult. My advice for a successful transition is to hire a few key people for the job. They can be neutral and objective driven. They won’t be attached to the past. As Ben Horowitz says in The Hard Thing About Hard Things: Building a Business, hire the right person for the right job at the right time.
For example, we brought in an interim CTO with excellent hiring skills. He assisted in the recruitment of a new team and also helped to shut down and optimise many of the systems from the past. His focus wasn’t on creating value via new technology, but on creating a framework that would allow us to start from scratch and grow.
3. Empower employees – and start doing
To create the right company culture to move forward, it’s key to clearly define the objectives of the business. Everyone in the company should be able to explain the goals of the business in the short, medium and long term. Basically, what’s the vision of the company?
All departments need to be challenged, not only the product and tech teams. Defining and sharing clear business objectives will allow each department to define their own goals in the form of OKRs. This will naturally result in a greater commitment from employees. Teams need to be empowered. This works both ways; don’t expect employees to be committed towards a mission they don’t believe in and without some expectation of reward.
You must also be indulgent of failures. Any initiative, big or small, which is aligned with the team OKRs is a step forward.
4. Be modular and flexible
If your current product is modular then you can iterate to make the product fit your new vision or new audience. For each project, we always reduced the work to the minimum number of changes possible. We prioritised the changes that impacted final customers over the internal ones. We phased out the latest over time. Start small, and iterate step by step. There will be some bumps on the road, but keep moving! As former American racing driver Mario Andretti said: “if everything seems under control, you’re not going fast enough.”
Don’t rush to start building your product from scratch, either. Make sure you’re doing it for the right reasons and have clearly identified the objectives of the rebuild. A must-read on the topic is the post from Joel Spolsky from Netscape. He says: “If you’re writing code experimentally, you may want to rip up the function you wrote last week when you think of a better algorithm. That’s fine. You may want to re-factor a class to make it easier to use. That’s fine, too. But throwing away the whole program is a dangerous folly.”
5. Get the right customers; and lose the wrong ones
“Firing paying customers? Are you insane?” This seems counterintuitive, but you should be clear on the cost of supporting a customer. If your current customer doesn’t fit your long-term vision, you should end the relationship. Doing this the right way, and managing users’ expectations, can take significant time and effort. You should start as soon as possible. Give enough notice to your clients and users so that they can manage the change on their side, making the process as painless as possible for all.
Going through all these changes takes time. Don’t underestimate the effort, but neither should you wait to kick off the changes. Be creative in the process. Don’t wait to be 100% ready to get on with things. Give it a go and apply the lean methodology: identify, change, assess and then adjust your course.
“If the team is resistant to change, it will take three times longer to put a new process in place”