Learning To See Through Other's Eyes

“How do people want to buy the product you’re selling?”

Angela starts the talk by sharing her experiences with products that were launched but did not get any utilization. For a couple of these products, she shares that the issue was not even about the interface or the usability. It turns out that the relevance of the product to the user and understanding how a user goes through your product are more important. The questions to be answered should be less focused on how easy it is to use and more focused on things like: “Is what your user looking for really there? Is the information that they need present?”

Getting started on Product Research

To get started on product research, you have to first specify the things you need to learn about. For Angela, this means being able to define the most actionable information. Not all information will be useful to you, and gathering a lot of information is difficult, so you have to economize what questions to ask. Angela shared some guidelines to help figure out which questions to ask:

1. What decisions do you want to make?
2. What do you want to be able to do after?
3. Is there a business problem?

After understanding what you have to learn, the next item to understand is where you are in product development and what type of research you need. Angela then shared a specific framework for determining the kind of research you need.

The idea is to determine what you’re trying to learn. Are you checking if your product is relevant to your user, or do you already know that your product is relevant and you just want to make sure that your users use it as intended?

People hire apps to do jobs for them

To better understand your product’s relevance to your users, Angela then shares a specific framework from Clayton Christensen called “Jobs To Be Done” (JTBD). Jobs to be done is a reaction to previous market research techniques which focused heavily on demographics such as age, gender, etc. For Christensen, it’s less about those demographic factors and more about just wanting a certain set of work to be done. People then “hire” or “fire” apps to do these sets of work.

Your product should allow your users to do what they want to do better than any other alternative.

Don’t ask why when trying to understand why

As you do your research and try to understand your user’s jobs-to-be-done, you will naturally have to interview a lot of people. To help out with this, Angela shared several tips when doing product research that may seem counter intuitive at first, but are actually very helpful for the researcher.

1. Don’t ask why — People tend to rationalize when asked: “Why?”. A better question is “What” or “How” as this allows you to see exactly what goes through a user’s mind.
2. Keep Quiet — People tend to fill in the silence. For researchers, this means that the interviewee will tend to explain more to fill in the silence.
3. Listen Actively — Don’t analyze as you are listening. Absorb first, dissect later.

There are already many techniques for doing interviews such as “Laddering” or the “5 Whys”. However, they all share the same premise of trying to get past opinions and preferences and being able to understand a user’s reasoning and guiding principles.

Empathy for users != Emotional Empathy

Lastly, we often hear the word “Empathy” a lot in the Product or Design field. Often, however, the empathy we hear about is just emotional contagion. This kind of empathy is when you feel the same way as your users. However, this kind of empathy is not useful in design or research as it only serves to make you feel bad about your user’s problems. Instead, the empathy that we need is what’s called “Cognitive Empathy”. Cognitive empathy means being able to understand what goes through the user’s mind, and being able to reason like the user would reason.

Overall, Angela wrap-ups by saying that it’s not so much about the specific techniques or conventions, but the idea of listening to your users and caring about how they work. Ultimately, the user would know what the best customer experience is.

Special thanks to Truelogic, Kalibrr, and Intercom for sponsoring the event.

Be part of our ProductPH Facebook group to get notified about the latest meetups here in the Philippines: goo.gl/Um75dV

Learning To See Through Other’s Eyes was originally published in Product PH on Medium, where people are continuing the conversation by highlighting and responding to this story.

Product PH - What we've learned while building stuff at OLX.pdf

For the second part of our series on the different aspects of Product Management, we brought in Bit Santos, CTO of OLX to share with us his extensive experience, not only in building out OLX but also in growing the team from a small team of devs during the days of Sulit.ph to a multi-functional team spanning several countries. For the event last May 30, we leveraged NuWorks’s amazing logistics to help facilitate our experiment of having the real-time Q&A courtesy of Sli.do.

Values > Culture > Strategy

After introducing the context of his experience in OLX and emphasizing the importance of context, Bit began his by sharing how strategy is derived from the culture of the company, which in turn, is derived from the values of the individual. The way Bit visualizes this is by drawing parallels when planning to drive through a road.

The values, representing the “Why”, are visualized as wide boundaries on the sides of the road that serve as guide rails to prevent the team from going off-track. The culture, representing the “How”, are visualized as narrower boundaries within the values. They effectively constrain the “What” even further and make it sure that not only do you value the same things, but you also express them in a similar way. As a more concrete example, Bit share the different ways of working they have at OLX:

He then proceeds to share how they’ve evolved over time going from Sulit to OLX, and how they’ve changed the way they work in response to the things that they valued as time went on. Bit also notes that the ideal scenario doesn’t necessarily translate to reality as well. An example of this is how they moved towards having product packs as a result of valuing the ability to have multiples streams of work, with each focused on a specific objective. Unfortunately, they didn’t have designers or mobile app developers to be shared across the teams, which meant that the teams always had to deal with interdependencies in their workloads.

Strategy is more direction and fewer details

Bit then transitions to the next part of his talk where shares the different ways they’ve made their strategy and plans. He started out by sharing that in the past, their strategy would be written as a massive collection of documents. This would then translate into a very complex set of balanced scorecards.

“Details change quickly, so the more details we put in our plans the less robust they will be.”

Over time, they realized that their current way of planning things put in too many to make any sense. Bit shares that ultimately, they realized that their strategy documents only really required four things:

• The current situation — Where are we right now?
• Statement of intent — Where do we want to go?
• Initial ideas for potential actions — What are some initial ideas on how we can get there?
• Freedoms and constraints — What are the things that we are free to do in pursuit of our goal? What are the things we’re not supposed to do?

Bit further emphasizes that a strategy is not the same as a plan. A strategy is about the best possible, and not the most probable. It’s about giving directions and not actions. It enables the team to make decisions on what actions based on the direction the organization is going.

Execution at OLX

Bit then shares the different ways that they executed in OLX. At the time that he joined, OLX was scaling, and they need a better process for managing their execution. They tried out Scrum, Kanban, and their own version of Agile. At the end of the day, Bit notes that Scrum created a lot of additional overhead, and wasn’t that good if the other teams didn’t buy it nor if there was a lot of unplanned work like maintenance work or changes in the product direction. Meanwhile, Kanban had a couple of advantages such as it was more of a set of principles rather than a fixed methodology, it had built-in sanity checks thanks to the WIP limits, and the bottlenecks were easily identifiable.

Aside from their development process, Bit emphasizes the need for making measurement an important product requirement. He highlights further that measuring and understanding your users is only the first step — you have to get a point where you can not only predict what might happen but also be able to prescribe what you should be doing given the current situation.

Bit ends the section by talking about the learning from the customers, and the different ways they’ve tried to do it OLX. He shares methodologies such as multivariate testing, usability testing, and design sprints. He also emphasizes that the design sprints don’t have to full-blown, 100% A then B tests are better than no tests, but ultimately, you also have to make sure that what you’re testing is really worth improving.

Q & A and closure

We rounded off the session by taking a look at the remaining questions from Sli.do and asking Bit to answer them one by one. The questions ranged from very high-level ones such as how the principles and values of OLX were formed and how involved the top management was in the formation of those principles down to the nitty-gritty like how was the KPI of a UX designer measured or whether a Scrum master should be present in their sprint planning or not.

What was really surprising though was the level of engagement that came from the audience as they began submitting more and more questions, and voting on them as Bit answered the questions bit by bit. It was a sight to see certain questions being voted and suddenly appearing at the top of the queue. We were also able to capture the questions that we didn’t have time to answer during the event and be able to discuss them post-event (see below). Overall, this event was very insightful for the organizers as we this was our first foray into actively introducing mechanisms to keep our participants engaged throughout the event.

Read about Bit’s answers to some of the questions here: https://productph.org/questions-on-what-weve-learned-while-building-stuff-at-olx-by-bit-santos-31f6ca75d571

Special thanks again to Bit for giving the time to talk at our event, NuWorks for the amazing venue, and finally to Intercom for the goodies!

Be part of our ProductPH Facebook group to get notified about the latest meetups here in the Philippines: goo.gl/Um75dV

Lessons learned while building products at OLX was originally published in Product PH on Medium, where people are continuing the conversation by highlighting and responding to this story.

As product managers, we’ve seen and used our fair share of various Agile frameworks such Scrum, Kanban, XP, and many others. In fact, we’re probably currently using one of those frameworks to build our products. For the last part of our series on the Fundamentals of Product Management, we’ve brought in Ian Pestelos to talk at the Zalora office last March 20th about how agile can be used in product management. Ian is an experienced agile coach, an active organizer of the AgilePH community, and has several years of experience working in an agile environment.

WTF is Agile?

Ian starts off the talk by sharing some textbook definitions of Agile and asking whether Agile is a framework, a culture, or if it had something to do with a fast development style. He then shares the story of a team he has worked with in the past who were able to build a product in an Agile manner, but ultimately failed to deliver business value. Ian highlights that while you could build products in an Agile manner, be it in terms of the development framework, your company culture, the speed of delivery, or your choice of Agile framework, it all doesn’t matter if you don’t achieve your expected outcome. He summarizes that being agile is just a starting point — the goal is not to have daily standups or sprints — these are only practices that help you build a better product for your user.

“Agile is not the goal, it is (a) means to an end”

Agile as a Learning Framework

So how do you build a better product for the user? Ian shares that Agile is a learning framework, and not just a software delivery framework. Instead of just looking at the sprints as releasing a potentially shippable product, you can look at the iterations as experiments. In this context, building in an Agile manner is necessary, but not sufficient. Yes, you need to move fast as you constantly create features and release those features in iterations, but more than that, you also need to learn more about the user as you experiment with them and the features you’re releasing. Ian then gives some concrete tips on how to use Agile as a learning framework.

1. Overcome Template-Zombying — Too often we get caught up in following the rituals of our chosen Agile framework, that we fail to realize the underlying intent of those templates. User stories are probably the most common example of this. As we attempt to follow the “As a _____, I want to ____, so that _____” template, we often get too caught up in following the template that it defeats the original purpose of communicating effectively.
2. Manage the System — Instead of expecting people to just give feedback on their own, you need to create an environment where people feel that it is safe to talk. Having psychological safety in the work environment helps create effective teams. As managers, if we want to create a safe space while still maintaining outcomes, we have to grow our own soft skills such that we can facilitate conversations rather than command.
3. Forest for the trees — Focus ruthlessly on the outcome. Specific activities like having retrospectives would not matter as much if the outcome wasn’t being delivered. Further, focusing on the outcomes allows us to workaround current existing constraints that may otherwise trap us.
4. Mind your gaps — You don’t know what you don’t know — we need to make sure we are constantly getting feedback from others and constantly improving. Even the two weeks gap between sprint retrospective might be too long when giving feedback.

Ian wraps up his talk by giving two insights on learning in an Agile manner. First, it’s important to remember that we should model the kind of environment we want to work in. Our teams won’t be agile if we aren’t agile. Second, we have to take into consideration that the best practices for others might not be best practices for us as well. Our teams, products, and markets are different — what worked in other teams might not be the best approach for ours. Lastly, it’s not enough to be agile in terms of product delivery and be the first-mover in the market, we should also be the fastest-learner such that we experiment all the time and learn fast.

How do you communicate to stakeholders about bugs that aren’t part of the specs?

For the succeeding part of the event, we entered into the fishbowl format to discuss the various concerns that the audience raised. The first topic was about how and when do you communicate to stakeholders about bugs for user stories that were not really part of the specifications. The main theme of the responses from the audience was that product managers needed a certain level of transparency and negotiation to make sure that as we communicate the issues to our stakeholders, we can accomplish what we need to, and that the stakeholders are aware that the issues exist, but will be dealt with separately.

How do you build psychological safety?

As the audience delved deeper on why we would encounter a situation where the team wouldn’t be comfortable talking about the bugs to stakeholders, we realized that there was the deeper issue of psychological safety in play. As we discussed psychological safety, various viewpoints were raised. For some, they felt that product managers should shield the team, particularly the developers, from the stakeholders. The rationale was that the stakeholder’s input had to be filtered since a lot of it usually doesn’t make sense at first, and will be a waste of the developers’ time. For others, they felt that it was better to get the developers to talk with the stakeholders — this was risky, but it also helped the developers to build their defenses better. Others also felt that the key to building psychological safety was to build it yourself and at the same time, demand it from the top leader in your organization.

How do you communicate better with developers?

As we continued to talk about building psychological safety, especially with the developers, the discussion began to shift to how to communicate better with the developers since as product managers, we didn’t want to disturb them unnecessarily. A couple of advice from the audience were:

1. As a manager, protect the “zone” time where the developers are focused on coding (usually afternoon), but make sure catch-up and talk time outside of the “zone” time (morning) is meaningful
2. Pool things you want to ask, write them down and wait for a time when the developers are ready to talk
3. Observe your developers. Having earphones on would usually be an indication that they don’t want to be disturbed. You could also check if they’re no longer doing work-related items since that usually means that they’re free to talk.

A couple of developers in the audience also gave the insight that as developers, they also care about the product. In some ways, they do want to get disturbed immediately for urgent concerns that would affect their current workload like critical bugs. However, the ask is for the product managers to judge what they should be disturbed immediately about since topics like a new feature request could be discussed in the sprint planning meeting.

Should the DevOps team be a part of the sprint planning?

We then jumped into a more technical topic about whether the DevOps team should be a part of the sprint planning. The question was rooted in a context where the feature developers are actually ready to push a new feature out, but the DevOps team isn’t able to deploy it into production. The initial set of reactions from the audience revolved around involving DevOps as part of the sprint planning — whether this meant including the DevOps team to the meeting or making sure that even the feature developers can do DevOps work. This triggered another set of reactions where people debated whether there was a need to have a separate DevOps team at all. Some of the audience who belonged to the Banking industry felt that the stringent standards for banking applications meant that they really needed a separate “production” team. On the other hand, others felt that it had less to do with industry and had more to do with making incremental changes so that they are safer to deploy in production.

What do you do when you have an ineffective product owner?

The next topic was about how to deal with an ineffective product owner who was looking to leave their role. In particular, what do you tell a product owner who is not able to manage the stakeholders well, and consequently, creates more work for the development team. In response to this, the audience mainly felt that Product Management is not for everyone. It’s a high-stress role where you really have to manage a lot of stakeholders. Others advised to introspect if the product owner won’t be effective in the next six months to a year. If they won’t be, then try to lead the product owner into thinking that they need to leave on their own. There was also a heavy emphasis on getting the Product Manager to own the product — that is, do whatever it takes to make the product successful.

As a team member, how do you influence decision makers to create a great work environment?

As we were beginning to wrap up, the conversation shifted into how do we actually foster a great working environment. After all, most of us were team members, and the decision makers above us were the people who actually had the power to foster the changes required to create psychological safety. In response to this, the audience gave three specific advice:

1. Understand what works as a communication style for you — As an individual, you would have a specific communication style that you are most comfortable with. Some people are more comfortable with being direct, while others are more comfortable with being more tactful. Some others may prefer to have validation first before even engaging in a difficult conversation.
2. Understand what medium the recipient understands the best — Different people have different ways of understanding concepts and ideas. Some people are more visual, while others are better readers or listeners. Some people don’t want confrontation, and some others are more receptive to ideas that they think they came up with.
3. Reflect back to yourself — At the end of the day, if you don’t have the courage to do it yourself, how can you demand it from others. That is to say, the question “How might we change others” can be re-framed into “How might I change myself”

Do you prefer product managers who you only see during meetings versus those who you see every day?

We wrapped up our event with the topic of what is your preferred kind of product manager: the kind you only see during meetings or the kind you see every day. Both sides could work, and both sides could fail, but the audience shared some interesting insights on this dynamic. The core insight was that you can choose to invest more time in having written documentation early on or pay the price of spending more time talking to your teams on a day-to-day basis to clarify what needs to be done. In most cases, a new team will typically benefit from a more present product manager since the environment of the team will typically shift on a frequent basis, hence the documentation becomes irrelevant frequently, and you will need to talk to your team frequently anyway. On the other hand, a more mature team will likely find such a product manager to be unnecessary and will likely appreciate a well-written documentation better as it gets the job done faster.

Be part of our ProductPH Facebook group to get notified about the latest meetups here in the Philippines: goo.gl/Um75dV

Building Beyond Fast and Slow was originally published in Product PH on Medium, where people are continuing the conversation by highlighting and responding to this story.

As Product Managers, we often get a lot of requests on daily basis. These various requests, while interesting, can easily clog our backlog and slow us down. Saying “No” allows us to focus on the things that matter and helps us achieve our vision. For the second leg of our series on the “Fundamentals of Product Management”, we brought in Jan Pabellon, the Director of Product Management at Netsuite, with over 8+ years of Product experience under his belt as our speaker last February 21st at the Canva office. Jan has extensive experience managing stakeholders across different countries for different platforms and shared some tips that proved useful to him for managing stakeholders over his career.

The Case of the Pentagon Wars

After introducing himself, Jan kicked off his talk by showing a clip of the Pentagon Wars movie. In the clip, we see Col. Robert Smith (aka. The “Product Manager”) present a troop carrier design to the military top brass. Although the initial design was approved, the top brass began requesting more and more features to be added to the original troop carrier design. Smith couldn’t do anything except to accommodate their results. What resulted was that the troop carrier morphed into a mishmash vehicle completely different from the original design, with a lot of features, but wasn’t good for anything.

Jan then points how Smith actually had a pretty good idea of what he wanted at the start, but because of his inability to say “No” to his bosses, his product turned into a mess that had no focus and no real use. He then presented his key takeaways from the movie and shared specific techniques that he has actually used for each takeaway.

Getting Everyone on the Same Page

Jan’s first takeaway was that for you to say “No”, you need to get everyone on the same page. He enumerates a couple of ways you can do this. First, by having a clear vision of where you want to go, you can align everyone with what you’re trying to achieve. He uses Apple as an example where Steve Jobs, by having a clear vision of the iPod and the Mac, was able to start revolutionizing the consumer electronics industry. He emphasizes that having a clear vision of what you want to achieve in the future, allows you to go back to it and get your stakeholders to be on the same page.

Second, another approach that has helped Jan by was presenting his product roadmap of where they wanted to be in the next couple of releases and linking it to the business strategy. Not only was this a way to align stakeholders on what’s going to happen in the next months or quarters, this also allowed Jan to implicitly say “No” to his stakeholders. If their request was on the roadmap, then they’d know when and what to expect already. Otherwise, they would know that their request was declined or at the very least, was not as part of the focus of the business strategy.

Finally, Jan shares a technique that helped him get everyone on the same page by articulating who the target segments of the product were. By clearly stating who you’re building the product for, it gives clarity to the rest of the team on how their requests are going to be received. Does it fall under the target market? Then we’ll mostly build it. Is a related but different segment? Then maybe we can consider, but it’s not a priority. If it’s completely outside of our target market, then we’ll have to say “No”.

Help them understand the trade-offs

Jan’s second takeaway was that for you to say “No”, you have to help your stakeholder understand the trade-offs. One of the specific techniques for helping stakeholders understand the trade-offs that Jan shared was to show the opportunity cost through the use of the iron triangle of scope/quality, speed, and cost. He emphasizes how you can only pick at most two at the expense of the third. Building a product quickly and for cheap will result into a crappy product, while building a high-quality product quickly is expensive. He also shares how this holds true, no matter what your software development methodology is — Waterfall holds the scope constant while varying the speed and the cost of development, Agile, on the other hand, holds the speed and cost constant, while playing around with the scope. He summarizes by saying that, ultimately, we can ask our stakeholder to ruthlessly prioritize what they’re asking for.

Jan also shares a common problem with managing stakeholders is the failure to weigh the short term versus the long term. It’s very easy to build a feature — it’s hard to maintain it. He shares how a lot of young companies often underestimate the amount of work need to maintain a feature and end up having a hard time maintaining as they grow and scale into other markets.

On the other extreme, another common problem that occurs when the product managers fail to say “No” is feature bloat. Often for more mature products, the number of features a product has will grow over time. If the product manager does not safeguard the product backlog, then the product will begin to lose focus, and a result, will alienate its users. Users would use only a small subset of the product’s bloated functionalities while viewing the other functionalities as an annoyance. As a result, this often results into users leaving the product, and often, translates into lost revenue as well.

Present your case effectively

Lastly, Jan’s final takeaway for being able to say “No” is the ability to present your case effectively. People are more often than not rational. By using facts and data to back up your decisions, people will be able to understand where you’re coming from and are more likely to accept your decision. Jan tells a story of how he prioritized their backlog of features needed to localize their product to various countries. He was getting requests from the different head of sales in each country, and each of them was asking for features to be developed before the product could be localized into their country. He then took a look at how valuable each country was in terms of potential revenue, and from there, he saw that roughly 80% of the total market share actually belonged to a select few countries. Armed with this data, he was able to prioritize these select few countries, and present his case effectively.

Another technique Jan shares for being able to present your case effectively is by shifting the frame of reference for your stakeholders. Jan elaborates how in Netsuite, their leadership in the USA was focused on developing features that mattered to the US, without seeing how the situation looked like in other markets. By telling the story of their growth in other markets like Australia or Japan, Jan was able to shift their frame of reference from a US-centric perspective to a global perspective with multiple markets other than America. This reshifted frame of reference allowed them to focus on the new markets that were still growing instead of continuing to push for US-centric features that actually prevent them from being effective in other markets.

Finally, Jan shares his last resort technique for being able to say “No”. One of the most powerful ways you can present your case effectively is by telling your stakeholders what is in it for the stakeholder. He shares how articulating to the stakeholder the negative aspects of their decision would haunt them later on and creating a detrimental effect on their ego and on their stature in the company. Overall, Jan emphasizes how important it is to talk the jargon of your stakeholders. The head of Sales wouldn’t care about how a certain feature gets built or what tech frameworks you use, but they would definitely hear you out if you talk to them in terms of potential revenue, profit, and loss.

“I didn’t talk about features, or that this will take X months, this will a re-architecture from this Javascript XJS library to this library.

They don’t give a f***. What they care about is the language of business.”

Conclusions and Breakout Sessions

We then wrapped up by breaking into groups of five for the discussions. Some of the interesting highlights from the QA and the group discussions revolved around managing HiPPOs (Highest Paid Person in the Office), How to prevent yourself from becoming a HiPPO, Dual Roling (or Multi-Roling) in a startup environment, and being able to protect your backlog.

Be part of our ProductPH Facebook group to get notified about the latest meetups here in the Philippines: goo.gl/Um75dV

How to say “No” was originally published in Product PH on Medium, where people are continuing the conversation by highlighting and responding to this story.

Joshua Pielago’s talk about “How to Build the Right Thing” last Jan. 25 at the DxC Technology office was the first of our series of talks for addressing key problems that product managers and how experience technologies tackled them. To start off his talk, Joshua briefly talked about his experiences launching 40+ products ranging from digital marketing products to SaaS products over the course of 3 years and the context of how their success could have been better despite them creating significant business impacts with the products that they built.

“Building the right thing comes first from knowing what the wrong thing is … No really knows at the start what the right thing is”

Joshua shares how there were several products that the team built that they felt were going to be amazing, but in hindsight, ended up being not very successful. To further illustrate his point, Joshua got us started on a case study of a couple of products that his team built that ended up failing even though it looked promising at the start.

A case study of building products

print.pdf

Joshua gave everyone a sheet of paper containing information about a hypothetical digital marketing company, it’s vision, business model, target market, business problems and and product ideas and strategy intended to solve those business problems.

We were then asked to form into groups of 4–5 people each to tackle the case being presented. In the case, we were shown three business problems, each with its own set of solutions, and goals. In brief, the product ideas where:

1. Product A: The company was experiencing low usage of the Product A, so they built a feature with the goal of increasing engagement from their users.
2. Product B: The company had no recurring revenue for a given category, so they decided to run a completely new service with the intent of earning at least $5,000 MRR
3. Product C: The company’s existence was at risk because it was heavily reliant on one core service, so they decided to diversity with the goal of having a more diversified portfolio that could account for at least 25% of the total company revenue.

The groups then started discussing the case, with each group trying to consider various angles. Some groups focused on whether the strategies were tied to the vision or whether they would be relevant in the long term. Others focused on whether the manpower and required resources were even worth it versus the project’s benefits.

After fifteen minutes of intense discussions, Joshua then asked for volunteers to start their insights on what could have gone wrong for each of the products. Most people had the idea that out of the three, only the diversification strategy would actually be successful, while the other two would most likely fail.

Case Study Results and Acid Testing

After hearing our thoughts, Joshua talked a bit about the concept of Acid Testing. The basic idea was that by asking a set of Yes/No questions about a given product idea, you’d be able to tell if the product or feature was worth executing.

1. Does it fit your vision?
2. Will it still matter in 5 years?
3. Will everyone benefit from it?
4. Will it improve, complement, or innovate the existing workflow?
5. Does it grow the business?
6. Will it generate new and meaningful engagement?
7. If it succeeds, can we support and afford it?
8. Can we design it so the reward is greater than the effort?
9. Can we do it well?
10. Can we scope it well?

If an idea had “No” as an answer to any of these questions, then it would be better not to execute on the idea.

Armed with this paradigm in mind, we then proceeded to walk through the cases again, and this Joshua guided us throughout the process of answering the questions for each product idea they had, highlighting which questions would later prove to become the tell-tales signs that would show that the ideas were going to fail. For example, for Product A, creating an engagement feature checked out everything except for the fact that they were not able to design it in such as way that the reward would be greater than the effort — this actually led to a very low engagement from their clients.

Product B, on the other hand, wasn’t something that the team could do and scope well, as a result, the sales team wasn’t confident of what they were selling, and in turn, weren’t able to sell it. Lastly, while the diversified strategy saw a measure of success in terms of diversifying the company’s revenue streams, it ultimately led the team to miss their overall revenue targets as they were not able to invest in their core product.

What helps in building the right thing?

Spend the most time on the problem, the user, and the scoping. Its impact is exponential to development.

Joshua then goes on to discuss how there are two main things that really helped him in building the right thing: Product Intuition and Paradigms. He describes the Product Intuition as the sum total of all the knowledge and experience one has related to products, and the ability to apply that knowledge and experience for problem solving. In his case, he had an HR background, but his interest in computers and the web since his childhood days had shaped his intuition, and has helped him be able to say no immediately to certain feature requests. He emphasizes experience in dealing with products, and the awareness of industry trends as the primary ways to build product intuition

On the other hand, Paradigms are models or mindsets that are shared by successful teams for building the right product. Joshua shares a couple of interesting paradigms:

• “How to say no” — Every time you build a feature, you’re going to stick with from inception and design, to development, to maintenance, up until the feature dies.
• “Focus on the problem” — The solutions you build can only be as good as how well you understand the problem
• “Use the Acid Test” — Using the simple set of Yes / No questions shared earlier to make sure every item on your roadmap is worth building
• “Start with a cupcake” — Build out products to be a cupcake instead of a wedding cake. The nuance that is that a cupcake is a complete product on its own. People are already going to be willing to pay for the cupcake — it isn’t a minimal cake that only has the cake base with neither icing or filling.
• “Set goals from the start” — Products do jobs. Goals are a measure on how effective the products are in doing the job.

Find the problem no one is solving and do it really, really well.

Breakout session and key takeaways

We wrapped up the session with everyone counting off into 5 groups, with each group discussing their key takeaways from Joshua’s talk. Majority of the takeaways were focused on the realization that they needed to really understand the user and the problem before they started building features. The acid test was also highly appreciated by the groups as a concrete way of letting them check if what they’re doing was really worth it or not.

Prior to founding LOKAL - Digital Marketing services in the Philippines, Joshua headed Product Development for a white label marketing agency that provides white label digital marketing services and web apps SaaS. He has also held positions as Head of Product for a Venture firm, and prior to that, he was Operations Manager for an offshore business services firm and a data analysis company.

Be part of our ProductPH Facebook group to get notified about the latest meetups here in the Philippines: goo.gl/Um75dV

How to Build the Right Thing was originally published in Product PH on Medium, where people are continuing the conversation by highlighting and responding to this story.

We invited top product managers from the all over the Philippines to share their various experiences ranging from how they got started in Product down to how they manage stakeholders and prioritize their tasks.

The event last December 12 at mClinica was a first for ProductPH as we celebrated our anniversary meetup by having a panel discussion with the some of the best product managers in the Philippines. We brought together a strong panel consisting of Iris Tiu from mClinica, Brian Mckiernan, VP of Product from First Circle, and Jan Pabellon, Oracle’s APAC Director for Product Management.

The discussion kicked off with the panel introducing themselves, their products, and how they got started into Product Management.

Getting Started as Product Managers

Iris started shared his story first of he started out as a game master for a GameClub, and from there moved to a Product Officer role. As a game master and as a product officer, he was mostly in charge of being the “expert” when it games that he handled. He then went out of his comfort zone to become a Senior Product Manager at Garena, where he pretty much handled everything from revenue to customer support for the product.

Brian went next by sharing how he graduated as an Electrical and Electronics Engineer and went on to become a hardware engineer for his first job, but he didn’t appreciate it. He then went into tech consulting for Accenture, where he started to get interested in Product Management.

Jan ended the round by saying how he graduated in accounting but realized it wasn’t for him. Instead, his first job led him designing a website, then proceeded with him learning web development. From there, he went to found his company where he learned to do a bit of everything until he got interested in a Netsuite’s Country Product Manager opening. He also shares a bit about how the product team is structured in Netsuite and how they interface with the other teams in the organization.

On the role of Product in the Company

Jan continues by expounding how they had specifics teams for each product area in Oracle, and each of those teams would work with a Product Manager who owns that specific area of the product. For example in Netsuite, they have PMs for various ERP areas like revenue management, taxation, etc. All the PMs then reported to a head of Product who managed the entire product portfolio.

Brian notes that for FirstCircle, their product structure is constantly evolving. He elaborates that from the time they’ve started, they’ve undergone several phases. The first phase was more manual, with the team focusing on really understanding the customer’s needs, they then proceeded to start to use technology to replace more processes like excel and cold calling.

“That’s why our customers come to us: for our money. They don’t come to us and be like, “hey, I really like your onboarding flow. It’s amazing. Good job.”

Iris shares that in mClinica, they built the product out of an opportunity for pharmacists to connect with their peers, and that their product team works very closely with various kind of developers across the organization. Iris also touches a bit on how he gets a lot of feedback from the business teams and how he fits the feedback into the product roadmap.

On Prioritization

Iris started this round by sharing his preference of first looking at what is the goal and then building a priority list on what would impact the goal the most. Jan then responds that he also started out with something similar.

However, as Oracle grew in scale and size, it became harder to align various priorities and agendas across different PMs. To that end, what really helped was splitting the vision per product area.

The idea was that by having each product area have its own vision that was tied to overall vision, not only did it gave each product area enough flexibility to maintain its set of priorities, it also made it easier to communicate the priorities to the stakeholders.

An interesting question was also raised by the audience on whether prioritization was a Project Management or a Product Management task. The panel felt that, ultimately, prioritization was a Product Management task, as ROI maximization is one of the success factors for a Product Manager. Nevertheless, the panel also noted that it was highly dependent on the organizational structure, and in some setups, the Product Manager prioritized what to build, while the Project Manager prioritized how to build.

Saying no to stakeholders

The conversation flows from prioritization to then communicating your roadmap and being able to say to no to stakeholders. Iris shares that he would go back to looking at what is really the priority, and communicating the priority based on factors such as what will generate the most revenue or what is the most used feature.

People need to trust you that you will do your job.

For Brian, people need to trust you that you will do your job. He emphasizes the need to sit down with everyone, share the vision, and win the trust of the people. He also emphasized the need for a central roadmap to communicate often and effectively to let know people why you do what you’re doing.

Jan then rounds the conversation by adding that the need to say no allows you to actually complete tasks. It’s not ideal to start off a lot of initiatives and not be able to complete any of them. Having a clear roadmap and saying no allows you to accomplish the things that you need to do.

What makes great product managers

Jan believes that it is typically the people who were naturally curious and were generalists that tend to be successful product managers. He expresses this as the kind of people who always go to events, and who have a hunger for learning tend to be more successful. Whereas, being a generalist allows you to understand the different kinds of backgrounds, and to be able to break the different silos in the business.

Brian echoes this and adds that for him, asking why is a very useful tactic. He elaborates further that you can often put on different “hats” and understand more by asking things like

“ Oh, I’m not in Finance, why would you need that feature? Oh, I’m not an Engineer, why would you do it that way?”

Brian also shares that he feels it’s important for someone to have a hacker mentality who is not afraid to takes risks.

The usefulness of MBA, higher learning, or coding when it comes to Product Management

Jan took a first stab at by saying that while having an MBA was not necessary for a Product Manager, it would be valuable if it could broaden your horizons. He elaborated this by saying that as a PM, you would be coming from different backgrounds. Some would be coming from a programming background, in which case taking an MBA would be helpful. On the other hand, if you were coming from a business background, then learning how to code would actually be more useful as it would make you more well rounded. The crux of Jan’s point was that being able to understand and communicate well with people from a diverse set of backgrounds would be beneficial for a Product Manager.

The conversation then zeroed in on how necessary it is for a Product Manager to code. The panel felt that it wasn’t a necessity, but being able to code helped reduce the time it took to be able to communicate effectively with the developers.

Transitioning from Project Manager to Product Manager

After the discussion on whether taking an MBA was useful or not, the floor was opened to the audience, and one of the questions that was raised was how to get started on transitioning to a product management role if you were coming from a project management role.

Brian felt that this had a lot to do with knowing the product. He shares that if as a project manager, you’ve been working on really small features, you might not have had the oversight of the entire product, so that would be an area that you’d need to brush up on.

For Jan, he emphasizes big-picture thinking and being able to see where everything fits. He elaborates that it means being able to see what the different teams are doing and how it all comes together to bring in revenue and make the business work.

We wrapped up the event with a breakout session where the audience split into three groups to discuss stakeholder management.

Be part of our ProductPH Facebook group to get notified about the latest meetups here in the Philippines: goo.gl/Um75dV

What are Product Managers Made Of? was originally published in Product PH on Medium, where people are continuing the conversation by highlighting and responding to this story.

ProductPH Talk - October 4th

Working with engineers is often painful for product managers. We’ve invited Tony Lee, a Dev. Manager at Freedom.tm, to give a talk about how to best work with developers to achieve maximum output. Tony has had 14 years of IT experience across several large companies like Microsoft and Blackberry.

Tony started out the talk with a quick introduction of himself, a high level overview of what Agile is, and what the Product Manager typically does. He then briefly discussed what were the four key challenges that PMs usually faced:

(1) Why cannot we finish all the features on time?
(2) Why are they’re missing the big picture?
(3) When is it too late to change the requirements?
(4) How to get more work done? Where is the bottleneck?

Value Delivery

To illustrate the first challenge, we were asked to split into groups, with each group having a pen and a paper. We were then asked to create graphs describing the value that we can deliver to our customers if our Dev teams were working on one project at a time as opposed to working in parallel on several projects.

The basic premise of the task was to deliver three features: A, B, and C. Each of them took a week to execute, and each will deliver $2000 upon completion. Further, context switching between each task took a 20% overhead of the time to complete. The idea was to graph the amount of value being delivery over time as we worked on the features, and to figure out whether it would be better if we worked on the features one-by-one or in parallel.

It wasn’t long into the discussion before people started realizing that working on (and completing) one project at a time enabled them to deliver value more quickly and consistently to the customer. This was in contrast to working in parallel, which not only led to the customer only getting their value after all the features were finished, but also meant that it took more time overall to actually finish the three tasks.

Penny Game

Another exercise that we did was the Penny Game to demonstrate how to better manage “Work in Progress”. The game was pretty simple, each group received 20 coins that they had to pass around members of the group. The catch was that each person had to flip ALL the coins first before passing the coins to the next person.

Naturally, this led to the observation that the other people in the team were doing nothing while waiting for the person who was currently flipping the coins.

This led to round two, where we each person would pass the coins to the next person as soon he or she has flipped the coin. Soon, everyone in a group was flipping coins and passing them quickly.

We quickly realized that not only was passing the coins immediately more efficient than passing it all at once, it also kept everyone was busy and nobody was just waiting anymore.

Ultimately, the idea was that by reducing the batch size of the work, and by limiting the amount of “Work in Progress”, not only would we be able to deliver a unit of the finished product faster to the customer, but we would also be reduce the amount of down time for members of the team.

Group Discussion

We wrapped up the talk with a quick discussion on the challenges that we faced at our workplace and how we could utilize the insights that we learned that night to tackle our own challenges.

The discussions were varied, and every group covered a lot of different topics ranging from releasing their first ever MVP to scaling their product teams. It was also quite interesting to see individuals from various fields like design or sales sharing their own challenges with working with developers and taking away insights and next steps from Tony’s talk.

Thanks again to Tony for giving the talk, First Circle for venue and food, and to Edukasyon for marketing the event!

Be part of our ProductPH Facebook group to get notified about the latest meetups here in the Philippines: goo.gl/Um75dV

How to Collaborate with Development Teams for the Best Output was originally published in Product PH on Medium, where people are continuing the conversation by highlighting and responding to this story.

Feature prioritization is a challenge that product managers have to face day-in, and day-out. In our meetup last September 6 at mClinica, Andreas gave a quick lightning talk about using the RICE model to prioritize features.

Rice Prioritization

RICE is a feature prioritization model that takes into account the following factors:

Reach — How many people do we reach with this?

Impact — How much does it impact one specific user?

Confidence — How confident are we about estimations?

Effort — How confident are we about estimations?

It allows us to rank and prioritize which features to build through the RICE score:

The higher score is, the more likely we should prioritize the feature. Andreas ended his lightning talk by sharing that RICE is just one of the many prioritization features out there, and there are several other methods that might be just as useful.

After Andreas’s talk on RICE prioritization, we broke up into groups for LeanCoffee to discuss our challenges and learnings.

Group Discussion

It was the first time we invited several people who were not related to Product Management to LeanCoffee. On top of the usual crowd of PMs and newbie PMs, we had people from AgilePH who were ScrumMasters, and even people from non-profit organizations and LGUs.

The diverse set of people brought several highlights into the discussion. Some took the chance to ask for advice about challenges they faced at the workplace such as “How can I do my job as a Product Manager better so that I don’t become a bottleneck to the team?” or “What’s the basis for a good design? When do I know if it’s good enough to go out to the customer?”. Others talked about specific products or technologies such as the latest trends in Credit Scoring or Fraud Analysis.

The varying perspectives also led to colorful debates about relatable topics like “How do you prioritize your backlog and manage your stakeholders?”. Some members of group strongly felt that protecting your backlog was key, while others felt that managing your stakeholders was more critical, especially in the context of when and how to say “No” to stakeholders.

Be part of our ProductPH Facebook group to get notified about the latest meetups here in the Philippines: goo.gl/Um75dV

Prioritizing your backlog based on RICE was originally published in Product PH on Medium, where people are continuing the conversation by highlighting and responding to this story.

ProductPH Aug. 2017: Lean Startup Night was originally published in Product PH on Medium, where people are continuing the conversation by highlighting and responding to this story.

ProductPH June 2017: Experience In Zendesk was originally published in Product PH on Medium, where people are continuing the conversation by highlighting and responding to this story.