4 D — Product Management Framework
Products are everywhere and have been part of our lives since long time ago. We use it everyday, from a physical product to a virtual one. Although we know that product is essentially made by human through some complex procedures, many of us might not understand how the concept of the product comes to life.
Once, I talked with a guy who has this idea of starting a business. He wanted to make a product, and he has this idea that he thinks might be a booming, one-million-dollar idea.
In his mind, the concept of product is simple: we poise through our everyday lives, we face a problem, we think of an idea, we think that idea is a great product concept, we make the product, and then boom, we build the right product with lots of customers.
Although I cannot blame him for thinking that way — and I do wish making product was that easy, I contend that making a great product, a product that customers love, requires more thoughts and considerations.
“At the highest level, creating software products involves figuring out what to build, and then building it.” — Marty Cagan
Marty Cagan and Jeff Patton has long came up with this term of dual-track development. They separated the product delivery — where we build the product, and the product discovery — where we actually come up with the product idea. I do think this is what we actually need to put our thoughts on before jumping straight to building a product.
Furthermore, based on their concept, I classified the stages in managing a product development into 4 different phases for a more detailed elaboration, which are: Product Discovery, Product Design, Product Delivery, Product Deduction
Product Discovery
According to Marty Cagan, Product Discovery is when we figure out what to build. However, what to build can range from a concept, an idea, to a concrete design waiting to be built. I reckon that in this Product Discovery, we should focus more on the idea and opportunity first, before we transfer to the solution domain. Those ideas and opportunities usually stem from a problem.
It is too often that we heard someone just jump into solution without truly scrutinizing on the problem first. As an engineer, I was trained to think about a problem first and then try to find a solution that can solve that problem, not the other way around; And it actually applies to the concept of product discovery, where it is a phase where our focus would be beamed toward finding and validating a user needs that is often based on a problem they have.
How do we find user needs?
User needs or ideas or even opportunities can come from everywhere, whether it’s customer success department, sales department, power user or even stakeholders such as C-Level. But we need to always treat them as assumptions. There’s nothing certain until it’s already happened. All we need to do is test out the assumptions.
How do we do it? Well, the answer is we have to ask the user whether they really are experiencing the problem or not. However, be extra careful not to take everything user said as the requirement, because sometimes user just don’t know what they actually need. They do know what they want, and they would tell you all about it; but even then, it might not be the right solution.
“If I had asked people what they wanted, they would have said faster horses.” — Henry Ford
User might not be suitable in telling what they want or providing solutions because
- They do not know what possible solution is out there or the advancement of technology
- They usually describe what they want and in a language that is convenient for them. Not what they actually need or what can be applied to the whole segment of user
- They do not see the product as a whole, where what they need might affect others
It is not user’s job to figure out what to build, it is their job to tell us what they actually need, what problems they face and what kind of value they wish to be incorporated in the product or service. Once we have talked with the customer, we can more or less validate our previous assumptions, whether it is actually true or not. And in the end, it is our job, the Product Team, to make sure those needs are met with what we want to build.
Job and Surface
Even when we find out their problem by talking to them , we should still tread carefully and try to truly understand the problem beforehand. To start with, the problem that we face or encounter during our daily lives are usually the surface of it. Once we start peeling through the layer of the problem and only then we can find the root cause of the problem. That root cause is the main thing that needs to be solved, not just the symptoms on the surface.
Clayton Christensen and Anthony Ulwick introduced the concept of Jobs-to-be-done framework, and it completely revolutionize the mental model I have in viewing problems in this world.
I used to think we should start with a problem, but if we are to see it from a bigger point of view, we can start to think about jobs.
People hire a product to do a job they are trying to accomplish. I hire a pen to do a job of writing some notes in my books. I hire a cup to hold a liquid that I am going to drink. And so on.
This can be translated that in our everyday lives, we all have various jobs that we are trying to complete, and using a product could help us to accomplish the jobs much easier, faster or better.
Now, when someone cannot complete the job that they desire to do, that is where the problem arise. The inability of accomplishing the job, either because the current solution is not satisfying enough or the solution itself is non-existent, is the pain point for the user.
All we need to do is to understand the constraint that are blocking them from reaching their goal, and provide the solution that can remove the blockage. In the example, if I do not have the tools called pen or notes, I would not be able to note down some ideas that just popped up into my mind.
However, as discussed before, sometimes even the user needs or the problem stated are only the ones residing in the surface. As a Product Manager, it is our job to dig deep down to discover the truth. One of the tools from Eric Ries’ Lean Startup can actually be applied in this case. The Five Whys, where we would ask why five times (not necessarily) to the point we discover the root cause of a problem, can help us in digging through the surface straight to the root cause.
For example (I take this example from a quote of Theodore Levitt, “People want to buy a quarter inch hole, not a quarter inch drill”):
A: I would like to buy a quarter inch drill
B: Why?
A: So that I can have a quarter inch drill
B: Why?
A: So that I can make a quarter inch hole
B: Why?
A: So that I can put on a quarter inch nail on the wall
B: Why?
A: So that I can hang a picture of my family
B: Why?
A: So that I can decorate my bedroom wall
B: Why?
A: Please stop bothering me *walks away
From the conversation, although we annoy someone (you should morph the question a bit so that it is less annoying), we get to discover that he wants to buy a quarter inch drill because on a higher level, he actually wants to decorate a lonely wall in his bedroom with a picture of his family. From there, we can get not only the functional part of the job, but to the point of emotional value of doing the job. And getting those user needs could fill up our arsenal of ideas of what kind of problems we want to solve with the solutions that we offer.
All those things discussed from above are seen from the point of view of user or customer. However, we still need to check the business side of the product idea. Is it valuable enough for the company? Does it provide high or decent return on investment (ROI) to the company? Will the customer pay if we provide an opportunity to solve the problem that they have in hand?
Once we have the people and business side of the idea, and we can confirm that this idea is the best opportunity to pursue, that is when we can jump to the solution side.
However, before that, we should also define the success metrics of this opportunity. The success metrics are the kind of measurement to see if this idea can be classified as a success or failure once we have launched the product. The metrics themselves should be tangible metrics that are measurable, like revenue, new user adoption, or current user engagement. Those metrics would be visited in the last phase of product management.
Product Design
At this stage, after we have a concrete concept of what kind of opportunity or idea that we want to pursue, and that the opportunity itself is something that users definitely would buy and use, it is time to turn that concept into a more tangible form. It is time for a solution design.
If in the previous phase we can’t take our eyes of the problem or user needs; then in this part, we unleash our creative mind in crafting the solutions. The solutions can come from building something new, using something in our artillery of products, or incorporating something that has been built from other team or other company.
We need to remember, that the purpose of this phase is to turn the concept into a more concrete form, not to build the solution itself. The concrete form of solutions can be in many shapes, some of them are:
Wireframe
One of my favourite design in showcasing the solution. Why? Because it’s cheap, it’s fast, and it’s easy to be built. Even I, who draw like five years old, can do it.
Wireframe focuses on structure. It just needs to show the layout of different component in the whole screen or display, and what those components can do.
Sometimes it is called sketch, because people often draw wireframe in a paper, resembling a rough sketch of a drawing.
Some of the tools for wireframing: Balsamiq, Axure, Visio, even Power Point.
Mockup
Mockups focus on the design. If in the wireframe we put lorem ipsum in the text or random drawing as a replacement for picture. In the mockups, we put the (almost) real case text and picture in the mockups.
The color, the font, the background, the image, all shall resemble the real case when it is developed. This way, it would be easier for the decision maker or the development team to build based on the design.
Some of the tools for mockup: Adobe XD, Sketch, Figma.
Prototype
Prototypes are for exposing the interactions. Sometimes, user needs to see the interactions to get the whole feel, the whole experience in using the product or feature. The feel when we swipe, the feel when we click, the feel when we tap.
Prototype can also be utilized to tell users or development team to which screen or page the user would be lead when they perform certain actions. It would make them understand the bigger picture much easier.
Some of the tools for mockup: InVision, Proto.io, Principle
Each of the different forms of design above has their own strengths and weaknesses. The more complex they are, the more time spent to build them. But in return, they would be able to tell a more exhaustive story than a simple design. It all depends on the problem we want to tackle, the story we want to tell, and of course, the resources that we have.
Is that it?
I wish. The focus of design is in solving user’s problem, not in pouring what we think would be the best solution according to us. It’s not a competition to see what kind of design is more fantastic or alluring, but to see if our solution fits with the problem, and if it actually put a smile in our user’s face. It’s not rare to encounter the product team (even I experienced it before) that sticks with a solution because ‘I have spent hours designing this’.
So, the best way to prove it then is, of course, to test it to our user. Usability Testing is one of the famous method to use in testing our design to our user. It can consist of a moderated and unmoderated one.
In a moderated usability testing, user would be asked to perform certain task while being moderated and monitored ‘live’ by the professionals. Live communication with the test participants is the key in this testing.
In a unmoderated usability testing, user is usually asked to perform something without the presence of a moderator, using certain tools of course. It offers a more natural environment, a faster process of gathering data, and even lower cost (for not setting up the equipment). Nonetheless, it provides less personal observation and a higher risk of confusion.
Aside from usability testing, there are other methods like Focus Groups, where typically lots of users gathered together to discuss certain design with a researcher; A/B Testing, where we provide different options to different group of users to see their reaction to each option; or survey, where questionnaire and survey are handed out to users together with the design to gather their input.
The feedbacks that we have acquired during the test would then be utilised to enhance our design and then we can test it again to the user until we get a more concrete design that is (mostly) accepted by our users.
Involving Engineering
This is actually something that I have read before and then encountered during the development process. Involving engineering team or the development team as early as possible could lead to a smoother process when we are moving to the delivery phase.
When the design team paint the canvas on how the feature or product should look and work, sometimes it might be a bit too much or not that efficient in terms of logic. Calling for engineering people to add a bit of logic and to check what is possible and what is more efficient can speed up the process.
Although it is the PM job to think about a feature/product that is feasible to be built, the expert in the field is still the engineers. They can chip in their ideas on how to make it more scalable, more powerful (in terms of performance), and at the same time, it might be easier to be built for them.
I usually involve the engineers to see the solution that we have crafted in the Backlog Refinement / Grooming session. They can shoot up their ideas on how to solve that problem, and we would combine it with the design team. This way, aside from getting great feedback from technical side, everyone would feel the ownership of the product or feature that they are about to built. Therefore, there should be no uncertainty when the feature has reached the Sprint Planning session.
Product Delivery
It is time for us to enter the kitchen (to make something, not to eat). Once we already know what are the dishes we want to make (I mean feature), it is now the job of the development team or the engineers to make them from a concept or design to a beautiful reality.
The delivery process started when the development team takes the design and concept, build it, and then deploy it to an environment that can be tested by users. Regardless of what kind of development method or framework that we use, the delivery process will revolve around those processes.
In my current team, we use the Scrum framework in delivering our product. It all starts with a Sprint Planning where we talk about what kind of backlog (backlog is a unit of feature or task that the development team will take on) that we want to pursue this sprint. The sprint itself lasts for 2 weeks or roughly 10 working days.
The sprint planning event can last for the whole day because aside from explaining the backlog, the user story and the acceptance criteria; the development team would chunk down the backlog into smaller tasks in order to get the backlog done, and talk about the data schema between Front End and Back End so that there would be no miscommunication during the development process.
Next, every day would be filled with usual Daily Scrum Meeting to talk about what has been done, what is going to be done today, and if there is any impediments that block us from achieving our sprint goal.
Near the end, there would be a sprint review where the development team would display what has been done in the current sprint and showcase the increment to the product. The point of this sprint review is to gather the feedback after the stakeholders have seen the product. The impending task would be put in the Product Backlog Item once again to be taken in the next sprints.
Not to forget, as we use the Scrum framework, there would be Sprint Retrospective where we reflect our current progress in the current sprint, and what can be done better by either adding a new process, continuing the current practice or removing the waste in the next sprint.
In terms of environment, it all depends on the Definition-of-Done that each team has agreed on. For example, in my current team, we agreed that our Definition-of-Done is when the backlog has been built, deployed to a Development environment, linked between front end and backed, tested, and has passed the test from Quality Assurance. Therefore, our done backlogs are all deployed to a Development environment.
Aside from development environment, we also have two other environments. Staging is for the User Acceptance Testing (UAT) purpose, where we can test the feature to our clients or users (sort of like beta testing), but with a cleaner database; or perform a performance and load testing to check the system capability. Development is too messy for testing, and would be aimed as a sandbox for developing anything. The critical point of staging is that the computing environment and database shall match the production environment as reasonably as possible.
And last but not least, we have the production environment where it is the live environment that would be used by the real users. The feature that are deployed into the production environment shall be the one that has been marked as stable. Any bugs found during the UAT would be reported, and thus the feature would not be deployed into Production until it is ready.
Product Deduction
This is the last phase of the product management cycle. I actually need to find a suitable name, and since I want to have all start with D, for the mean time we should go with ‘Deduction’.
The deduction in this phase means we ought to deduce whether the feature that we have deployed or built can be considered a success or not. As we have defined the success metrics before in the Product Discovery phase, it is time for us to revisit the success metrics and check if we achieve our goal or not.
In building a product, we shall not aim toward the output, rather we should set our eyes on the outcomes. If we keep on counting the number of features that we have developed, then it means that output is number one in our mind. It’s not about the numbers of features that can be spawned by a development team, but what the original purpose are. Don’t we agree that we build a product to solve user’s problem? Whether our built product can solve user’s pain and put a smile in their face or not is the thing that we shall measure, and it is called the outcome.
Suppose we encounter a report saying that our user adoption rate is not as much as we want it to be. And upon investigation, we found that it might be due to the registration process that is taking too much steps and too long. Then, we test that assumption and found out that user actually does not need several information of the registration, and those lengthy registration process is making them lose interest. And thus we design a new registration process, design it, test it with user, build and deploy it.
At the start, we have agreed that this new registration process is made to improve user adoption and make the registration process faster. If we stop when we deploy it to the user by saying “Great, I have made an improvement to the app. My job here is done”, then it is dead wrong. We should go few steps further by checking if user is indeed affected by the new registration process. And whether the effect is within the course that we want to set or not.
The success metrics could be something like reduce the registration process from average 25 seconds by 25%. Or it could be coupled with increasing user adoption rate by 25% within 1 month. All of those metrics should be measurable within a specific time set, and then should be measured accordingly. Once we have achieved those success metrics, only then, we can say that we have a product success.
Even if we are wrong, we can learn something from there. It means that there is something wrong with our initial assumptions, or possible with the design that we have crafted. We should strive to learn about the reasons behind those failure, and attempt to fix that within the next iterations. This way, even when we fail, we get validated learning about our customers and keep improving. The point is, never stop learning.
After a product success, it does not mean that the job here is done. This is just a single cycle of the whole product management cycle, and it is our job to go back, look at the data and feedback, and start from the beginning again. Product itself has no end.
