How Would You Create Product That Customers Love?

Hai My name is Rizkah and two weeks ago I started my Summer Internship at Amartha as a Product Manager. I’m diving into this job without having any experience before, so Kiki Ahmadi as the Product Manager of Amartha as well as my mentor during my internship in Amartha recommended me to read a book from Marty Cagan called “Inspired: How To Create Tech Products Customer Love”. Marty Cagan is a partner at Sillicon Valley Product Group, specializing in product teams and product strategy (former exec at eBay, Netscape and HP).

I read this book during Ramadhan holiday and I will discuss the important points discussed in this inspiring book throughout this article. So let’s start.

Pic Credit

Product Teams

There’s no exact rule that says all product teams in a company need to be the same size. However, product teams usually have one product manager, one product designer and 2–10 engineers. Collaboration between the members that is not hierarchical support the product managers, product designer and engineer are able to work out the solutions together. The ‘good’ product team is when every member sits right next to each other. It doesn’t mean they are in the same building or same floor, but it allows every member to be able to look at each other’s computer screens. The group of best companies has learned the value of getting the employee to work and sit together as a team.

There’s one quote that I love so much from Inspired book by Marty Cagan, it said:

“We need teams of missionaries, not the team of mercenaries”.

Mercenaries mean that we may build whatever they told us to build but missionaries are true believers in the vision and are committed to solving problems for their customers.

Product Manager

The honest truth is that product manager needs to be among the strongest talent in the company. Product managers must have a passion for the product (which is something you can learn), aware of the technology sophistication, have the business savvy, show credibility with the key executives, have the deep knowledge about the customer or have respect for their product. However, the most important thing is that despite of all these skills, product manager is also responsible for the team performance. As Marty Cagan said in his book “When a product succeeds, it’s because everyone on the team did that what they needed to do. But when product fails, it’s product manager’s fault”. That quote represents if product manager held so much responsibility for product team.

To be absolutely clear “product manager is not the boss of anyone on the product team”. They work together to solve a problem and the results of their work are reported to the functional manager, in this case product managers usually report their work to the head of product. The relationship that is owned by the product team is not reporting relationship.

Product Designers

There are common and serious problem that often happened in the company. We, as a product manager, try to do the actual design by ourselves. This is a serious problem since we rarely provide good results and don’t provide the full holistic design that we’re looking for. This could be happened because product manager have not been trained in designing skill. There’s also product manager that don’t provide design but, they rather provide very high-level user stories to the engineers. However, in order to begin coding engineering team need the design, so the engineer usually have no choice but work out the design by themselves and this is absolutely serious problem.

The modern product designers sit side by side with his or her product manager, product designer is a full partner with the product manager as long as you do product discovery.

The Engineers

As a product manager we need the strong relationship with engineers team. If the relationship is not strong, our days as a product manager will be brutal. The purpose of developing this programming literacy is not for telling your engineers how to do their job but, I would rather to significantly improve your ability to engage with and collaborate with your engineers.

Supporting Role

We’ve talked before about product manager, product designers and engineering team role. However, there are other people in supporting roles we will also work with. Such as user researches, data analysts and test automation engineers. These people maybe will not dedicate solely to product team but at least we know why they exist, and most important is to know how to make the best use of the people.

Good/Bad Product Teams

As I mentioned earlier, a good product team is a product team that has the principle of “missionary-like passion” and the bad team has “mercenaries”. Good product teams get inspirational ideas from their product vision, analysing data, analysing customer problem, and bad team gathers requirement from customers and sales. The good teams likes to brainstorm with the best leaders from other companies that share the same vision but bad teams is easy to get off by getting advice from other companies. Good team has product manager, product designer and engineering team that sit side by side but bad teams sit in their respective silos and ask that other make requests for their services in the form of document and scheduling meetings. Good teams always constantly innovate their product but bad teams wait for assignment from their supervisor. Good teams engage other customer every week to ensure and got prove customer feedback with their ideas while bad teams act as customers.

That’s some difference between good teams and bad teams that I can explain after reading Marty Cagan book, other difference can be found after gaining experience in good teams and bad teams itself.

THE RIGHT PRODUCT

Before I discuss what is the composition and best practice for the product team, I will explain briefly how to determine what product team should be working on in this section.

One of the key arguments in this inspiring book is that we have to focus on outcome and not the output. As we realize that typical product roadmaps that we create are all about output. Yet, good teams are asked to deliver business results. However, every roadmap we built are all about output. Normally, we define product roadmap as a prioritized list of features and projects that team have been asked to work on, but the fun fact is roadmaps are the root cause of most waste and failed efforts in product organization. Why is that? Because sometimes customer choose not to use our product because simply they don’t excited about this idea that we have even if our ideas is valuable, usable, feasible and viable, it typically takes several iterations to get the execution phase.

In order to avoid that to happen, product team must have modified their product roadmaps so that each item is stated as a business problem that need to solve, rather than the feature or project that may or may not able to solve. Marty Cagan said these are called outcome-based roadmaps.

Product Vision

Product vision is the most important that must exist before we built our product. Product vision describes what are we trying to create in the future, typically somewhere between two and five years. If we want to make a good product we must have a product vision that I mentioned before and in order to realize it we must make something that we called “product strategy”. Usually, product strategy is geographical and based on achieving a set of key milestones in some sort of logical and important order. For example, in first release we simply deliver critical rating and reviews function for e-commerce platform, and next release leverage the data generated from customers to create product sentiment and next leverage these data to give product recommendations for customers.

The most important when we built product is we have to focus on one single market (focus on one new target marketing or one new target persona for each release). You’ll find that the product will still likely be useful to others, but at least it will be loved by some, and that’s key. In order to do that we have to defined product vision first then create the path to achieving with product strategy.

THE RIGHT PROCESS

After knowing the right person for each product team and what each team needs to focus, next I will explain how product team to their job.

When starting to built a product, product team usually starting product discovery. At the product discovery stage there are two things to know:

1. Discovering what the customer need and making sure that the solution we give works for our customer problem and for our business
2. We need to ensure we deliver robust and scalable implementation that our customer can depend consistently reliable value. Although we’ll never 100 sure and confidence, we should not to have to release and pray. So, we need to learn fast, yet also release with confidence.

So the purpose of doing product discovery is to have evidence that the product that will be built it will not be a wasting effort. Before stepping into product discovery, every member from product team should be able to answer these 4 questions, (1) What business objective is this work intended to address? (Objective); (2) How will you know if you’ve succeeded? (Key results); (3) What is this problem solve for our customers? (Customer problem) and (4) What type of customer are we focused on? (Target market).

After we finished product discovery, we move right into the product backlog. Many teams now consider a high-fidelity user prototype and a story map as their go-to techniques. There are 4 principles of prototype that we have to run, that is:

1. Feasibility prototype. On feasibility prototype engineer will create typically code — the ideas is to write enough code to mitigate the feasibility risk. This prototype have a small percentage of the work for the eventual shippable product.
2. User prototype. This is the most important techniques for every product teams, so it is well important to developing our team’s skills and experience in creating user prototypes at all levels of fidelity.
3. Live-data prototype. On live-data prototype the actual users will use the live-date prototype for real work, and this will generate real data (analytical) that we can compare to our current product or to out expectations to see if our new approach performs better.

After our prototypes done the next step we have to do is testing. There are many different kinds of testing that can be done, such as usability testing, value testing, demand testing techniques, qualitative value testing, quantitative value testing, feasibility testing, business viability testing, etc. I will not explain the detail of every testing in this articles but the most important thing is that we have to know that in doing this testing is we will get actual data that product team can be used for doing analytical report for the next step.

Analytical skills is very needed in product team. With this skill, product team can understand user and customer behavior, measure product progress, prove whether product ideas work and inform product ideas. This so important after all as Marty Cagan said the worst thing about product decision in the past is its relate on the opinion that the person who is initiated it, the more that opinion counted.

The most important from analytical report is we can find some very powerful product. Some of the best product work going on right now was inspired by data. Yes, usually we often get a good idea from observing the customer, and studying the data itself can provide insights that lead to breakthrough product ideas. Note that we often refer to analytics as key performance indicators (KPIs).

SUMMARY

The thing that I have mentioned above is a step for us as a product teams to build product that customer love. I hope we can follow these tips, but of course not all theories can be realized in practice because we have to adjust the existing environment will be but the things I mentioned are some of the best practices that we can try. Maybe there’s lot of inaccuracies on this article so I recommend you all to read Inspired book from Marty Cagan and learning more about how to be good product manager.

Rizka is a computer science student from Universitas Indonesia which currently taking summer internship program as Product Manager in Amartha. If you are a final year students looking for experience and skills, Amartha might be a good fit for you. Introduce yourself to us by sending email along with your latest CV to careers@amartha.com.