Product success magazine: Customer Centric Product Management by Prodmagazine

EDITOR’S NOTE

INSIDE

WHEN WAS THE LAST TIME YOU MET YOUR CUSTOMER ?

‘Customer is king’ might sound clichéd but they are the sole reason for the existence of any company. Businesses build lasting relationships with their customers based on the value they create and the problems they solve. Customer delight is essential success criteria for both large businesses and new startups and every type of company in between. Product managers have to ensure that customer centricity is paramount in every decision they make during the value creation and delivery. ‘Customer is king’ might sound clichéd but they are the sole reason for the existence of any company. Businesses build lasting relationships with their customers based on the value they create and the problems they solve. Customer delight is essential success criteria for both large businesses and new startups and every type of company in between. Product managers have to ensure that customer centricity is paramount in every decision they make during the value creation and delivery. I have the good fortune of experiencing product management in large technology companies to being a founder and working on both successful and not so successful startups. My experience over the last two decades shows that you can change the strategy and fortunes of your company by keeping close proximity to your customer — the one who pays and consumes what you create. I have seen broadly the following important phases where customers can be a driving force.

Validation during early stages of your business Irrespective of the size or stage of your company, you need to be speaking to your customers early on. This is important to validate your assumptions and get insights into the problems you are solving. Product managers tend to be more arm chair and assume that they have found the magic potion to the problems. This often leads to disaster, when the product reaches a market and is rejected by customers. In my experience with my first startup idea, I worked on for several months with assumptions and solutions based

HOW TO BUILD AN IOT PRODUCT ROADMAP To create a working solution, all layers of the IoT Technology Stack need to work together.

PRACTICAL PRODUCT PRIORITIZATION Most product geeks try to prioritize their feature backlogs instinctively. Here’s a framework to fit your priorities better.

STARTUP LIFE: THE ART OF PRODUCT ROADMAPS The roadmap is one of the key deliverables for a product leader. It is important to communicate goals, priorities, and urgency.

THINK OF IT LIKE THIS: WE ARE A PRODUCT EXPERIENCE TEAM (PXT) As leaders, we need to be open to how our first impression of what the vision was might be reshaped.

FEATURE PRIORITIZATION I think it’s time to share the method I use for feature prioritization with the product development world.

EDITORIAL TEAM

EDITOR’S NOTE

on the technologies which I felt were must for solving the problems. This was in the area of analytics for telecom service providers. I had to pivot my idea once I met the right ‘people’ in customer organization to realize that they were not looking at solving the problem and hence my solution is not relevant for them. I realized that the same solution was relevant in a different market and took a pivot.

Co-creation of products and solutions As mentioned earlier, one of the competitive advantages you can create is your customer proximity. The closer you are to your customer, the deeper your understanding of the problem and you will have an internal champion on your side. Many times this proximity creates opportunities to co-create products and solutions, as the customer will have confidence in your abilities and provide you sufficient information to solve their problems. Customers also provide sandboxed environment to try the solutions, technical expertise and act as testers for the solution. This is a sure shot success formula as the user is on your side finding solutions. Contractually, this is the best solution with the pilot/lead customers and you should look for a win-win commercial. We had a very close working relation with a leading e-commerce venture and they gave us sufficient feedback on the product and showed how we could fix the problem in their system. We co-created a product which, once completed, was in demand with other e-commerce companies as they had the same problem. We shared the risk and made the solution at very little cost for the partner customer and made revenues out of others. The caveat is that there are risks in this model with intellectual property ownership and revenue share, but this has to be handled contractually and with skilful negotiations.

Being brand ambassadors The product manager’s responsibility is not just in creating products but also to generate profitability around the product.The work goes beyond processes and practices, and more into softer aspects of brand and customer relationships. Customers are the best brand ambassadors and if they can speak on your behalf to other customers or investors or even with

a testimonial, it adds a lot of weight to the product. However, it’s not easy to get this endorsement, it’s a craft product managers have to learn and maintain. It’s a small world in business and word spreads fast.

Extending shelf life Product managers have to manage not just new products but also the cash cows and end of life products with the same focus. The most challenging aspect is to manage products who have peaked on the product life cycle and need a shelf life. It’s difficult to invest into products in this phase and business decisions become extremely important. I had the good fortune of handling such products in my career, where the products were extremely successful in the market for several years as cash cows and facing the end of life.We made an interesting strategy of investment and product roadmap based on Lead customers.We identified customers globally who will have an investment in this space for the next few years (emerging economies) and worked out an agreement of Lead customers with them. They get to define the product roadmap with a commitment of business of a certain volume in a time period.This gave product managers a definite and clear strategy backed by customers and the product got its shelf life. Smart product managers should also utilize this opportunity to add innovations that can be bundled with customer feedback but delight them too. Product managers are intrapreneurs and they need to share the responsibility of customer engagement with sales and account managers. The relationship with customers will enable relevant innovations, product roadmaps and early validations. We should also not forget the value of customer testimonials which can boost the business. If you are a product manager, do a reality check.When was the last time you met your customer?

Ravikiran Annaswamy Founder & CEO | Woises Editor | Prodmagazine.com

HOW TO BUILD AN IOT PRODUCT ROADMAP

Let’s face it. Building an IoT product roadmap is hard — much harder than building roadmaps for ‘normal’ technology products. That’s because IoT products are complex systems. To create a working solution, all layers of the IoT Technology Stack — device hardware, device software, communications, cloud platform, and cloud applications — need to work together. It’s like having to manage five products in one, and your roadmap needs to be the glue that keeps all your stakeholders aligned with your vision.

The IoT Roadmap — Your Key to Aligning Stakeholders and Teams An IoT roadmap needs to show the product direction as well as the impact of new features in a way that makes sense for all stakeholders. Your stakeholders might be from Sales, Marketing, the Executive team, Engineering, and more. They all have different needs and different levels of understanding of how the product is put together.

PRODUCT ROADMAP

In fact, IoT introduces additional complexity because even the technical implementation is probably split across multiple groups. Depending on your company’s structure, you might have dedicated teams for hardware vs. software, embedded vs. cloud development, etc. No single team will have a holistic understanding, which makes it even more important for you (and your roadmap) to communicate the full picture. Because of this complexity, managing an IoT product is similar to managing a portfolio of products, with the distinction that ALL the products in your portfolio need to work together to form a cohesive solution. Not an easy task. The key to creating a solid IoT product roadmap is to balance a high-level view of the end-to-end product with more detailed views at each layer of the IoT Technology Stack. That way, you’ll be able to provide the right level of information for your different stakeholders and ensure nobody loses sight of the big picture.

Building Your High-level IoT Product Roadmap Let’s use an example to illustrate all the moving parts of an IoT product roadmap. Let’s pretend your company builds industrial water pumps. After talking to a lot of customers and sales folks, you discover that a major concern for

your customers is to keep operations going at all times.They would like to know if a pump is about to fail so they can proactively order parts and schedule service. This would reduce downtime and save them a lot of money. Such ‘predictive maintenance’ is very valuable to your customers, and they are willing to pay a lot for it. Researching solutions with engineering, you learn that as a pump ages, it starts to vibrate.The more it vibrates, the closer it is to failing. Therefore, if you were able to monitor pump vibration and perform analytics on that data, you’d be able to predict failures. With this information and some business due diligence, you determine this is a great solution and you are ready to put it on the roadmap for internal buy-in. Your high-level roadmap might look something like this. As you can see, this is no different than the roadmap for a non-IoT product. The challenge here is that it is very difficult for your stakeholders — Executives, Sales, Marketing, and Engineering — to understand what it will take to build this functionality and what the final product looks like. It’s also difficult to understand why release #1 will take 6 months and release #2 and #3 will be shorter.

PRODUCT ROADMAP

Using Story Mapping to Enhance Your IoT Roadmap For your IoT roadmap to convey the full story, you need to provide another level of detail describing the features of the high-level roadmap across the IoT Technology Stack.

I’ve found that story mapping is a great way to dive into this next level of detail. I like to combine story mapping with the IoT Technology Stack to show how features align with the various layers of the end-to-end IoT product. The result is a visualization that is still higher level than a ‘product backlog’, but gives enough information for all teams to understand the big picture. This view also empowers teams to understand how the planned functionality relates to the day-to-day work they’ll need to do. Here’s how this approach would look for our ‘smart pump’ example. From this view, it is easier to explain the work that needs to get done to support the predictive maintenance functionality. Notice how the names of the high-level features in the previous roadmap became the theme for

each of the releases. This helps your team keep an eye on the big picture while still focusing on smaller details. Notice that not all layers have to be impacted on every single release. In this example, there

are no features in the ‘Communications’ layer after release #1. This example assumes that the release #1 features in the ‘Communications’ layer will be able to support the functionality of releases #2 and #3. From this visualization, it is easy to see that release #1 is the only one that impacts your device’s hardware. Therefore, it’s easy to explain why release #1 will take longer than other releases. You can also see that fewer layers are impacted in releases #2 and #3. The initial release will be the longest because you need to build a lot of infrastructures. Once you build that initial ‘plumbing’, then you’ll be able to add features on top of it at a much faster pace. You can use this tool to explain that evolution as well.

PRODUCT ROADMAP

Using The Roadmap to Coordinate Engineering You can also use the story mapping roadmap to coordinate multiple engineering teams across various layers of the IoT Technology Stack. Every team needs to share a unified vision of where the product is going. But at the same time, they need to understand the work that lies ahead for their specific team. This roadmap can help you with both goals.

The Bottom Line As a Product Manager, you will always face challenges when communicating the product vision throughout your company. It’s a difficult task, and yet it is probably the most important function of our role. The approach outlined in this post provides you with a very powerful communication tool you can use to clearly express your product ideas and get everybody

As shown below, you can take ‘vertical slices’ to create specific roadmaps for each engineering team across multiple releases. As long as the data format and the interfaces between layers are well defined, this approach will enable each team to work independently and make progress faster.

aligned. The result: increased transparency, which results in better communication, happy teams, and happy customers.

Daniel Elizalde Founder: TechProductmanagement Author | Prodmagazine.com

PRACTICAL PRODUCT PRIORITISATION

I talked to over a dozen Product Managers around the country and found that most product geeks try to prioritize their feature backlogs instinctively.They do put efforts to evaluate features under Impact versus Effort framework, but, in most cases one of the two plays a dominating role in decision making. For larger funded startups with spare resources, it is Impact — they don’t care much about how many resources it takes. At the same time for smaller early stage bootstrapped ones, it is Effort — they focus on building what they can build quickly. Also, at different stages of the Product life cycle, their focus areas change. Most PMs did not notice that they were not making conscious

efforts in balancing business, technology, and user experience, which, everyone says is what product management business is all about.

PRODUCT LIFECYCLE

So, instead of oversimplifying your analysis with Impact/Effort or Kano Model or losing track of the primary balancing act, I figured a framework where most PMs could fit their priorities better.

7. Engagement feature – will hold the users longer, bring them back often

Here it goes.

9. Security feature – keeps your product/ users/data safe

1. What’s the stage of your product in PLC? Early, Growth, Early Maturity, Maturity, Decline?

10. Instrumentation feature – helps you measure and monitor health of product

2. What feature bracket can you fit your feature in to? Here’s a list of brackets in no particular order: 1. Parity feature – a feature competition (if any) already has

that

the

2. Expected feature – a feature that’s naturally expected from your product. Also includes conversion and revenue related features 3. Advanced feature – something only power users would love

8. Viral feature – will get you more users

Now based on the stage of your product in the PLC, you can determine what bracket should take precedence and hence prioritize accordingly. In early stages, you’d focus more on Expected and Parity features. However, as you grow, the Viral and Engagement features get higher priority. See the invisible framework on how these brackets get different priority based on what stage of PLC your product is in — UVTimes Blog Post. Thoughts?

4. By-products – what perhaps 3rd parties are providing on top of your solution. Check my last post for more details. 5. Unexpected feature – unsolicited, clever addon that can delight users in certain situations 6. Repayment feature – reducing technical debt, legal debt, compliance related stuff

Ujjwal Trivedi Sr. Product Manager: CouponDunia Author | Prodmagazine.com

STARTUP LIFE: THE ART OF PRODUCT ROADMAPS

A few startup founders have expressed to me how frustrating it is that there’s not a good template for product roadmaps. A simple Google search shows that there’s a lot of advertising and very little substance to this simple question. So I thought I would take a stab at this. The roadmap is one of the key deliverables for a product leader. It is important to communicate goals, priorities, and urgency.

So let’s start with the purpose of the roadmap: • Clarifies what the team needs to build when. • Clearly communicates who is working on what.

PRODUCT ROADMAP

• Gives a clear sense of priorities for projects and goals. • Finally, helps the team understand what the goals are, why those are the goals and what the overall product strategy to achieving those goals are. Non-goals of the roadmap • A long list of features and metrics without clear priorities or motivation. • A detailed spec with all dependencies and tasks, a roadmap should be easily digestible and does not include every implementation detail. • Something so rigid that it leaves the team no room to adapt. • A huge surprise for anyone involved with the product. So here it is:

My template for a high-level roadmap Structure of the template: • Overview — quick clear why and how for the roadmap. • Focus areas — represent the key strategic investment for the product. Usually also represent teams. Each focus area should have a success metric and list of key features or things you want to build. • Key dates — optional but for some products, there are hard dates like conferences or Black Friday or Back to School that are important to highlight. • Details — keeps the roadmap simple and digestible by moving mocks/specs and other details into links.

FAQs: How long should roadmaps be? Long enough for the team to focus and make progress, short enough to adapt and be flexible. This depends on your product? For instance, hardware products will naturally have longer roadmaps. For software companies, particularly consumer products, I like yearly goals and quarterly roadmaps. It’s healthy to check in every 3 months or at most every 6 months to see how the world has changed and whether you’ve made the right bets. It also forces the team to think more MVP style when they build products. How detailed should they be? I’ve seen and even attempted roadmaps that are extremely detailed with dates, tasks lists, dependencies, etc. I’ve found that those tend to fall apart pretty quickly and they fail to empower the team working on them to adapt and be creative. So my personal preference is to have a more digestible and simple roadmap and leave the details of the day to day planning to the team leads. Some teams work well with detailed documentation and Gantt charts. Others work more fluidly. The best way forward for me has been to work with great people, communicate the strategy and the why, and hold everyone accountable for the outcome regardless of role/title. How should it be communicated? I recommend a team or company-wide presentation to kick off a major roadmap. It’s important for everyone to know this. In this type of meeting, try to inspire and nail the why and ideally include some wireframes or aspirational mocks that get the team excited. Leave room for feedback. How do you build a roadmap? Top down or bottoms up that’s the question, right? Especially with consumer products, everyone has ideas. I like to do a combination. The leaders of the company should have a clear

PRODUCT ROADMAP

set of goals. They most likely will set the focus areas and investment priorities. For example, we’re doubling down on Android, this is the year. Or we’re investing in something new and risky. However, the key to this is that there’s good communication between the leaders and their team, so they’re getting ideas/feedback from the team continuously. Then as much as possible, leave room for the team to be creative. Have the

team leads, whether they’re PMs or engineers or designers, lead the details of a focus area. How do you improve personalization? Let the team working on this day to day set the roadmap for a focus area. In startups, the company is often small enough that this doesn’t matter. But it is something to think about as the company scales. Remember …

So be comfortable with change :). I hope this was helpful. I have been doing some consulting and advising work with startups, so let me know if you want some help or have any feedback or questions on this post.

Rose Yao Director Product: Google Author | Prodmagazine.com

THINK OF IT LIKE THIS: A PRODUCT EXPERIENCE TEAM (PXT)

Just go with me on this little journey. In my mind, I have been thinking about all of my product, user experience, and development friends. I wanted to try and provide some ammunition to a group of you who are still working in an environment that will not allow you to break free of old stodgy ways of working and work in way that will free teams to explore the new world of how Product Experience Teams (PXT) work and solve problems together. Just go with me on this little journey. In my mind, I have been thinking about all of my products, user experience, and development friends. I wanted to try and provide some ammunition to a group of you who are still working in an

environment that will not allow you to break free of old stodgy ways of working and work in a way that will free teams to explore the new world of how Product Experience Teams (PXT) work and solve problems together.

PRODUCT EXPERIENCE

It still comes back to a philosophical difference at the leadership team level. Either you believe the product is simply a hired gun to execute the leadership team’s vision and to be told what to do and how to do it. It then pours down those execution ideals to development teams and other parts of the organization to implement. OR You empower, trust and confide in the product organization to drive the company’s product strategy, execution and potential re-shaping of the company’s vision. Remember, vision can still come from the top but like I have always said, teams own and lead the implementation of the ideas. As leaders, we need to be open to how that could reshape our first impression of what the vision was. You build teams to get as close to the customer as possible. (I call these listening teams) Teams bring together and involve the entire company in that tribal knowledge and findings from those efforts. But the most important part to get right is that the user breaks the tie. We need to shelve

our personal bias, eliminate unilateral decisionmaking power over features and experiences, and let the users and their repeatable data teach teams how they use your product. I refer to this as a Product Experience Team (PXT). Okay, what’s this all about? For starters, please stop building teams around features. Build teams around experiences. Sure we have features in there but that’s why we keep building crappy products because we focus solely on the feature, not the experience/journey the user takes through a product. Just to be clear, in the below diagram, you can place a persona, experience or a big idea in the middle. All of the practitioners’ clan up and work to find common ground and glean confidence by working together, having healthy conflict and solving complex human-centered product problems together. The chart below ‘Product Experience’ is a way of structuring a team around a persona. Each product team in my mind is what I call a product couple. Product Experience Manager, User Experience Designer, sprinkle in at least four

PRODUCT EXPERIENCE

developers, and bam! PXT. (Side note: always try to keep the teams small.) These individuals are all responsible for the experience inside the product. For example, the Skills Development Leader Team (see chart below) is responsible for the ‘Reporting Experience’ which has several different features within it. That way when they build the reporting experience, they can think of all the ingredients that need to be in place to surprise and delight users. Is this making sense?

A LITTLE MORE ABOUT PRODUCT EXPERIENCE TEAMS (PXT) If I were to describe what my teams do everyday, I would say 85% of their time is discovery driven. We focus on the experience of the product and the direction it should take. The title we use to describe these individuals is a Product Experience Manager or PXM for short. As for the other 15%, I would say that most of this is organizing, communicating, and collaborating

with different parts of the organization to inform them on what’s happening when. A little project managerish if I am being honest, but I hate to say those words. Nothing against project management. I just don’t see it as necessary if you are building these types of teams. DISCOVERY DRIVEN: What does discoverydriven mean? It is the study and practice of ethnographic techniques, combing over qualitative data from prototype observation interviews, aggregating qualitative responses from a voice of customer sessions to define the next path forward and a deep review of quantitative datasets once the product has hit the streets at scale. This does not replace User Experience Design which embodies much different techniques but instead couples itself even tighter to the task flow diagrams, journey maps, hot spots drills and user story mapping practices. This also includes our development teams at a very significant level. We don’t think

PRODUCT EXPERIENCE

of development and product as a different group sitting on the opposite side of an aisle. Developers

are all part of the ethnographic research with PXM and UX design in daily work. They are the technical side of the conversation and thinking we bring to building a product. This can all work in matrix organizations or can report to one

leader, be it the CTO or CPO. The point is, they are one experience team. We have nine of these teams all cross-functional, co-located. Below is an example of what this actually looks like.

PRODUCT EXPERIENCE

Here is a great story from one of our Product Experience Managers for a first hand account. Our product experience managers are the catalysts for joining the organization’s arms together to understand the human centered connection between our product and the true reality of what is possible. There needs to be a day where we stop aligning teams and organizations around features. Customers have experiences. Sometimes they use features while passing through your experience. It is more important to begin aligning teams around these experiences to fully understand what customers are doing along their journey. If you are in one of these organizations that receive ‘requirements’ from above you in the

organization, it’s time to sit them down and educate them about the true value a PXT can bring. We will change their vision. We appreciate their ability to explain how they see the execution of that vision but ultimately if we do our jobs right. The user will break the tie regarding what I would mostly quantify as a conjecture. Thanks for spending some time reading through this and sharing it with folks. All of you are my inspiration and reason for writing.

Nate Walkingshaw Chief Experience Officer: Pluralsight Author | Prodmagazine.com

FEATURE PRIORITIZATION

I know I told some people that I would be uploading a podcast post, but I will leave that post to another time as I think a feature prioritization blog post has priority over my daily podcast habits. If that’s what you were looking for, here’s one (that I very much appreciate). For a while I’ve been thinking about sharing the method I use for feature prioritization and today is that day. Before I continue, I need to say that there are a bunch of ways to achieve this, even the old school product meeting that takes forever and always ends up with someone saying, “Please guys, can we go for dinner? It’s 10:30 already.” The method I use was introduced to me by a friend of mine (I really don’t remember who) and after I’ve applied it and refined it, I

think it’s now time to share it with the product development world. First things first: To follow the rest of the post you should download the guideline document for this method here.

Step-By-Step exercise In the shared document, you will see the following structure of columns: Features (A),

FEATURE PRIORITIZATION

Status (B), User Interest (C), Development Effort (E), Business Interest (G) and Completed (I).

people in Product, Development, and Business are at the table.

Features (A) — List of features that are in the pipeline for the next sprint you want to prioritize. If this is the first meeting and the team is just starting the first prototype, you should avoid listing all the user authentication features and mandatory features (ex: login/ signup/user profile).

– After you’ve created the list of features, the document will multiply the number of features by 5 and divide it by 2, the result of this operation shows how many points each team member has to distribute in each of the columns. The scoring scale goes from 0 to 5 for columns (C),(E),(G), which means that each team member will have ((nº features*5)/2) to distribute in his column. So for example, if there are twenty features to be discussed, each team member can distribute 50 points. By now, you’ll probably have noticed that by dividing the multiplication by two, the method forces you to choose wisely and prioritize.

Status (B) — Status of this feature by the end of the exercise, it can be a GO if the feature should go to production, or a NO GO if the feature is not a priority and should be added to the Icebox. – User Interest (C) — The user interest column should be filled by the product owner and of course, if possible, only after he carried out intensive user research and carefully read product metrics and usage reports. If possible, user feedback should be taken into account, just look into your notes, CRM tickets and old emails. – Development Effort (E) — The scariest column of them all, mainly because when you call a developer to a product meeting they will always tell you “- I really don’t want to throw a deadline here “. With this process, the CTO or the Lead developer aren’t supposed to come up with a date (or a deadline) but rather with the effort, it will take to accomplish each task. – Business Interest (G) — Business Interest is owned by the CEO or any other BD team member. In this column, it should be clear how much of a priority is this feature for the business team. Usually, this comes down to whether a feature is needed to meet a specific KPI or a key business decision. If that’s the case then it should be prioritized. – Completed (I) — Over time we’ve noticed that sometimes there are features that are already in the making or almost completed. If so, just point that out in this column. Method: Make sure the product owner has already listed all the features and that the key

– Each team member attributes their scoring to each feature while the product owner oversees the process. Next, to each feature, there are three questions that are then answered and graded according to the scale previously defined. Those questions are:: ” Is it important for the user? “,” What is the development effort for this feature? “, ” Is this key for the business? “. This grading loop goes on until the last feature is prioritized. – Once done grading each feature, the document will show how many points each team member can still allocate or has to remove.You can check these outcomes on row 3 of each of columns (C), (E) and (G). Because people tend to give higher scores to each feature before the first review, at this stage it’s way more likely that there are a number of points that need to be removed. – Each team member should then review their table and end up on row 3 of each column with either no points left or some that he doesn’t need to allocate. Now that the exercise is complete, the product owner can extrapolate the outcomes and final conclusions. Note: please avoid discussions throughout the meeting or at least keep them to the minimum.The product owner should now sum the differences between each team member’s scoring (the results that appear in columns (D) and (F)). If the result is 0

FEATURE PRIORITIZATION

or positive the feature is a GO. If it is negative, it’s a NO GO. Add a note to column B of the document so you remember later on. – Send this document to the team and let the CEO have a go an it ( but not too much, if you know what I mean ). Finally, add the next sprint to Trello or any other tool you’re using for task management.

members. As I mentioned previously, this is a method that I’ve been following for a while but if you think there’s something wrong with it, or if you know of or are using any other methods, please feel free to reach out on Twitter. Thank you to the person that first showed me this method, even if I can’t really remember who that person is.

Note: Don’t forget that there will be some feature requests and bugs to deal with in between product sprint meetings. Usually it’s the product owner that has to prioritise these. I hope this method will help you bring those long and unproductive product meetings to an end as well as those endless discussions between team

Diogo Teles Senior Product Owner, Booking.com Author | Prodmagazine.com

Editorial Team RAVIKIRAN ANNASWAMY Founder & CEO | Woises Editor | Prodmagazine.com

Ravikiran is incubates various innovative products using analytics and deep learning. He works closely with global programs like Founders Institute (Fi.Co) and Unreasonable Institute as Mentor and Coach for early stage startups.

DANIEL ELIZALDE

TechProductmanagement Author | Prodmagazine.com Daniel’s area of expertise is Product Management for the Internet of Things (IoT). He has managed IoT product portfolios and the complete lifecycle of end-to-end IoT solutions.

UJJWAL TRIVEDI

Sr. Product Manager: CouponDunia Author | Prodmagazine.com Ujjwal has more than 12 years of experience, working on emerging technologies, creating B2B and B2C mobile, web and desktop software for consumers and businesses. He helps businesses deliver by creating engaging products, and catalyzing sales.

ROSE YAO

Director Product: Google Author | Prodmagazine.com Rose has been a product manager for over 12 years. Most of Rose’s career has been spent on large scale consumer experiences. She’s focused on developing her skills on the business side.

NATE WALKINGSHAW

Chief Experience Officer: Pluralsight Author | Prodmagazine.com Nate is most widely known for developing Directed Discovery, a methodology that allows an organization to be human-centric by shifting the focus on user experience. Nate is also the author of Product Leadership.

DIOGO TELES

Senior Product Owner, Booking.com Author | Prodmagazine.com Diogo is a founding member of DarkMatter Collective and is currently working on new products for booking.com. He’s a ‘product guy’ with a tech and design background.

To contribute please write to â&#x20AC;&#x201C; editor@prodmagazine.com Subscribe to magazine at www.prodmagazine.com Prodmagazine

@prodmagazine