In the last post I was writing about the core responsibilities of a Product Manager: The product perspective, the business perspective and the technical perspective. So far, I was mainly talking about what a good product solves: A user problem.
But what’s also important is, to find more than one user with that problem – or in other words: to find a market for the product – or the other way round?
This post explores the thinking process behind the product design, but also how a good development system fuels it.
Product Market Fit
The goal for the product manager is to find so-called Product Market Fit – a term originally coined by Andy Rachleff, CEO of Wealthfront (more on A16Z). It‘s more or less a fancy term for finding a product that manages to attract an audience.
Starting small
The Product Manager and/or the team starts out with a hypothesis what a user might want. Then they talk to potential customers to figure out if their assumption were right. The goal is to get a rough feeling for the usefulness of the product, then to build an early prototype, and launch it to a market. Then the team evaluates if and how the product is used and collects feedback. Based on this feedback the product is improved upon, launched again, evaluated again,… and so on.
Instead of designing the perfect product from scratch, that takes forever to build, development teams are able to create value for the user fast and make sure that they are building something that creates user value. Essentially they take baby steps towards building a powerful product.
Take a second to think about this: That concept is super unintuitive. It‘s like aiming to build a car and starting out with a skateboard instead of a steel frame.
Building on a strong base
Also, consider the first iPhone. It didn‘t have apps, nor multitasking, nor iTunes,… But every iteration made the product better and better, one use case at a time. And as (at some point) even the apps one the phone started to get better iteratively, this effect started multiplying.
But it makes sense from both user and producer perspective. If you want to go to work and you can between walking or using a skateboard, skating is maybe not such a stupid idea. And as a company you don‘t need to invest into huge machinery without knowing if the user even has a use case for the product.
What‘s interesting about this idea is, that this approach requires a radically different approach to the development process. The goal is less about executing a bunch of defined work packages, but about consistent, fast and predictable iterations that are regularly shipped to the user.
This way ideas can be evaluated quickly and user value is created frequently. The team moves towards finding Product/Market fit.
The Development Process
As mentioned before, many large scale organizations still struggle with iterative development. So the question is, why is that? I believe it‘s a mismatch between conservative executives that still don‘t get the difference between classical project management and iterative development or have a hard time implementing it.
Project vs. Product Management
Classical project management – the „Waterfall“ approach – is in some way the exact opposite of agile development. You take a problem, slice it into its smaller parts, get everyone into a room, and discuss the deadlines of each milestone.
This approach works great if you are building a house, where each step till the end of the project is laid out in advance. There is a clear path to success that is visible from the beginning.
Most of the time software development is quite different, at least if you are building something innovative and new (which you are doing most of time as a PM). Technical solutions for complex problems can be quite tricky and might require extensive research in advance.
Plus – as mentioned in the previous chapter – the ideal product might not be visible from the beginning. You can use prototyping and user testing in order to find a solution that is understandable to the user. Steve Jobs coined the phrase „I know it when I see it“, which essentially makes the point that you can not be sure about the details of your product unless you (or your user) tried it out first.
Agile Development
There are some frameworks that try to solve those issues. One of the most popular ones is agile software development, also often referred as SCRUM (which is a so called agile framework).
I could go hours into the SCRUM process, what its principles are and how it works but as said, my aim is not to turn this into a PM manual. I think there are many resources where you can read about that.
Here are 2 of the most important principles when it comes to agile development from the PM’s perspective:
Bottom Up Empowerment
The first one is the believe that the experts, the people that actually do the development (engineering, design, testing, communications…) are crucial in every step of the process and are empowered to make decisions.
What follows from that is that the product manager has to communicate the product vision very well. Everybody on the team has to be on the same page concerning why a product is build. Only if that is the case, everyone is able to make optimal decisions.
In my last post I mentioned following when writing about the development perspective:
As a Product Manager, you want to encourage discussion and create a room where ideas can flow. You have to be careful of the boundaries and goals you set for your team: Too narrow and you will end up with a good-enough solution. Too far and you will potentially run into over engineering. Focus is important, but so is creativity and out of the box thinking.
I think this is THE crucial quality of a product development team, that separates high performing from low performing ones: Is the team able to direct their creativity and problem solving skills to solve customer needs effectively?
The only way you can achieve this is team empowerment. However, this requires a team that is constantly looking to improve as everyone is crucial for the collective success.
Iterative Improvement
The second one is the so called Deming cycle, the basic principle that underlies iterative processes:
In many companies one cycle (= sprint) is completed within 2 weeks with the goal that at the end of the cycle there is a shippable product that can be evaluated and improved upon. If you are in B2B, those are usually the cycles when you review the progress with the customer.
The SCRUM framework suggests a meeting outline that makes it easy to bring this cycle to life: Daily standups to check on the progress, weekly story reviews to improve the quality of the specifications, and so on. Even more, it frees cognitive capacity for everyone in the team to focus on their own duties.
Conclusion
Finding product/market fit is a tough challenge: Markets are saturated and there is plenty of competition. Having a good product development process supports the search by providing a great framework that encourages creativity and taking over responsibility.
During my time at Runtastic and now also at Mindbreeze I’ve seen quite different implementations of the process. From my perspective each company has to find out what‘s working for them. Requirements differ and so do the individuals who have to live to process.