My Blog

Agile

Digital Product Strategy

  • by marco

Develop a Digital Product Strategy

MARCO NESPECA

Define

To define product strategy in the simplest terms possible, we could say that it’s all about ‘envisionsing your product’s future.’

Creating a product strategy is exciting because you can imagine what kind of product it will become, who will benefit from it, and in what way it will create value for the users and for business. The most important part is documenting all those ideas to describe the following in detail:

  • Target users of your product and their motivation to use it
  • What makes your digital product different
  • Imagine the product fit into the broader company vision 
  • It’s contribution to business goals

I always start with developing, understanding or studying the existing product strategy, whether it be traditional or digital. This is important because it helps you focus the launch of the product and minimising risk and achieve a product-market-business fit.

Market fit

Business has strategic plans for the future and so a digital product must also have its own strategy and destination. To do this we work to create a solid product strategy.

Research & Discovery – Start by defining the vision and goals for your product as well as figuring out customer challenges and validating possible solutions. This process involves doing some qualitative research to understand how many people are facing those challenges and how big of an impact you can make by solving them through your digital product. This will influence your design and development decisions.

Product value proposition – What are the specific challenges your product is going to solve.  Your unique value proposition is not so much about what problems you solve, but how you solve them and how you can do it differently form the present.

Benchmarking and competitive analysis – Evaluate and benchmark available products and understand your competitor’s strategies for achieving their objectives with what they are offering.  Assess strengths and weaknesses and design a strategy that positions your product within the market.

It’s all about the Users – Learn everything you can about the users.  Who they are, what drives them, and what they look for in digital products. Creating user personas helps you visualize and communicate who your users are and their needs before setting a long-term product roadmap and strategic vision.

What are the product goals

Define your product’s goals. This is an extremely important step as we want to understand the benefits this product will bring to both the end user and the business.  Once you’re clear about the goals we need to peg the right key performance indicators (KPIs) to measure the product’s performance.

Product concept – Conceptualization planning includes the creation of User Journeys, User Stories, User Scenarios, and Use Cases. As a result, you can ensure that you’re reaching the right audiences – and give them the right digital paths that will guide them.

Product pricing – Your documented product strategy should describe how you will price the product, including its perceived value and a price model.

Expectations – Research the needs of the users in order to align the digital product and technology with users’ expectations.

A documented digital product strategy is necessary to make a well-researched product that people will want to use. Immediate value is always business critical but expanding the business in respect of the digital product strategy will continue to create value for business and users.

Agile

Small Teams, Better Results​

  • by marco

Small Teams, Better Results

MARCO NESPECA

Build then scale

Resources are certainly a necessary ingredient to getting things done. When a product is in the build & scale phase, excellence in hiring and on-boarding quality talent faster than others is a potential competitive advantage.

A small team just big enough to ship and iterate the minimum viable product, has it’s advantages at the earliest phase of a product, in the pre-product/market fit.

Communication hang

The cost of communication increases exponentially as the team grows due to the nature of cross-functional team structure which requires everyone to be up-to-date on the plans, designs, strategy, etc in order to ensure success.

Increasing team size early therefore increases the effort to communicate as things are moving and learning quickly with the new information flooding the team that needs to be appropriately communicated. Therefore the smaller your team size, the lower the communication overhead that you experience. While there are various techniques to reduce communication overhead, ignoring it and allowing poor communication on the team will effect the quality and velocity of work.

Keeping your teams small can help you guarantee communication velocity and limit overall overhead, allowing the teams to move quickly when change happens.

Faster decision making 

Decision making also tends to slow down on larger teams. This is because stakeholders end up involved in decisions, more people and their input is often needed to make decisions, and more socialization of the decision needs to happen.

With a very small team decisions can be made fast. There are usually very clear decision makers and far fewer people to convince and get buy-in from. When an organization has very clear decision rights on who owns a decision, they can often scale decision-making in larger teams. But while this works in theory, in practice it can be very difficult to truly manifest. Especially at the earliest stages when project members often want to feel they have strong input into the direction of the company.

Therefore the smaller the team the more naturally quick decisions can happen. Decisions on product features, decisions on target customer, decisions on acquisition strategy, monetization strategy, and maybe ultimately even the decision to pivot. There are a million decisions to be made and the speed of your decision making can make all the difference.

Alignment

After decisions are made, you need to ensure that the team is aligned on them in order to keep them motivated and working at their highest level of performance. To do this you end up spending significant effort building buy-in for the decision or for your team and capabilities to make such decisions in the first place.  With smaller teams it is easier to find that alignment since there are just far fewer stakeholders that need to be bought off on the decision for directions to change.

Agile

Build Through Continuous Feedback​

  • by marco

Build Through Continuous Feedback

MARCO NESPECA

Using feedback in product correctly

While all product teams leverage customer feedback to inform product decisions, most fall short of designing their customer feedback loop to maximize the benefits by gathering, recording, and synthesizing feedback back to the product team. Often treating customer feedback as a point-in-time activity as opposed to a far more helpful continuous process. Here are some techniques I’ve used for developing a product’s continuous feedback cycle, designed specifically to maximize the benefit of the customer feedback that organizations are already listening to.

Catalog Your Sources of Feedback
The first step is cataloging the various sources of customer feedback. Relevant customer feedback can come from a range of sources and it’s important to think about each source, the relative strengths and weaknesses of the feedback from that source, and how it fits into your overall feedback cycle.

Sources of feedback

Customer Interviews – product team’s typically conduct interviews with either existing or prospective customers to learn more about their needs and experiences with their product. These could be customer validation interviews, persona development interviews, usability studies, and more. Customer interviews provide one of the best sources of feedback due to the depth of learning you can get from getting into the minds of users. However, they are often one of the most expensive sources of feedback from the time & effort it takes to gather it. While teams often do these at the beginning of a project, it’s important to invest in them in future iterations of the product as well.

Customer Surveys – While customer interviews allow you to get depth of understanding of your customers, customer surveys allow you to scale your feedback process to larger audiences and to achieve statistical significance in your findings. These surveys can take multiple forms as well, whether it’s market research on potential new product areas, or gathering feedback from your existing customers on their experience. For example, periodic Net Promoter Score surveys serve as a strong compliment to individual customer interviews by moving from anecdote to quantitative findings.

Customer Support – Customer support is talking to your customers every single day, providing a wealth of knowledge on pain points, bugs, feature suggestions, and more. It’s important to create a forum by which this feedback gets regularly bubbled up to the product team for review and action.

Customer Metrics – Your customer metric dashboards and funnel analyses provide a view into what’s resonating with customers and what’s not. Knowing what parts of your product are regularly used vs not helps you quickly determine areas to double-down on or areas that need work. While they can’t tell you how to fix the problem, they do become an important source of where to conduct further research.

Sales – If your product is sold through a sales team, the sales team is an incredible source of knowledge as they are talking to potential decision-makers of your product every day. It’s important to find ways to bubble up what they are hearing on a regular basis to the product team. You need to be careful to realize that their feedback will be coming from decision makers and not end-users and you’ll need to analyze it appropriately.

Employee Feedback – Employees using the product often have great suggestions on additions. You need to be careful here though as their feedback will often reflect power user feedback as opposed to those experiencing the product for the first time with far less motivation.

Social Media – Depending on your product’s audience, you’ll inevitably find feedback on your product across social media, whether it’s Facebook, Twitter, LinkedIn or blogs and reviews published across the web or reviews on the App Store or Google Play store. It’s important to not only use these sources as a feedback mechanism and a pulse on the sentiment of your product and brand, but also as a channel to engage those customers when appropriate. The bias with these sources are that feedback is most often polarizing – it’s either coming from your strongest advocates or your most dissatisfied users.

Customer Success – B2B SaaS companies have started developing large customer success teams responsible for driving the adoption, engagement, and continued growth in the usage of their products within existing customers. These are also the best source of adoption blockers from your largest customers and should have plenty to say on how to drive quicker and more wide-spread adoption of your product with customers.

Churn Surveys – It’s becoming common for companies to send feedback surveys to customers who have canceled or stopped using their product for some time. It becomes a great source of feedback on exactly how you lost your customer. The response rates on these surveys are typically low given the lack of motivation of churned users so you’ll have to wait awhile for appropriate signal. And you’ll need to think through this feedback carefully, because you may ultimately decide that some of these churned customers are not your ideal customer as opposed to assuming you need to action their feedback into the roadmap.

Develop a channel

Setup a feedback channel – a place for anyone who is interested to get direct access to primary feedback on the product from across various channels. This has typically taken the form of an internal feedback channel such as Slack or HipChat. Typically it is important that all product managers, designers, and engineering leads have access to this, but everyone on the team should be encouraged across R&D, marketing, sales and customer service. 

All feedback that is gathered across the various feedback sources is then encouraged to be shared in a reasonable aggregate form on this channel. For example, let’s say the product team conducted a set of customer interviews. They are encouraged to provide both links to interview recordings as well as summarized feedback on the channel. As another example, the customer support team usually has a designated person who sends a weekly customer feedback report on the channel with details of top issues that customers have been facing as well as links to reports for further details.

This setup ends up having several benefits. First, it provides product managers, designers, and engineers the ability to regularly hear feedback directly from its source as frequently as they would like regardless of the source of origination. As an organization gets bigger, take more effort and get out of the building and actually talk to your customers . It’s a great way for exisiting and new team members to quickly and authentically hear the voice of the customer and understand what excites them most about the product and their pain points.

While it ends up being a high-volume channel that can get noisy at times, the benefits of the ease of sending feedback this way as well as the broad transparency end up outweighing any disadvantages. 

Develop a recording system

In addition to developing a high-volume feedback channel, setup a feedback system of record. This becomes the source of truth for consolidated and aggregated feedback across various feedback sources designed specifically for facilitating roadmap planning.

The goal here is to create a highly systematized process such that as new feedback comes in across the various input sources, it is quickly and efficiently processed into the system of record. For each unique piece of feedback received, it should have a short description, one or more feature or product categories it falls under, and names or counts of the requestors. 

Capture examples:

Spreadsheet – Google Sheets, Microsoft Excel – The simplest approach is to create a shared Google spreadsheet with columns for the description, category, and requestors. The benefits of this approach is that it’s quick & cheap to add items and most people are familiar with it. Though the drawbacks are that it creates yet another tool the team has to use in addition to their project management tool.

Project management tool – JIRA, Asana, Trello – Alternatively creating a ticket for each unique feedback item and then adding the additional details as fields or in the ticket description. The advantages here are that your team is already familiar with the tool, it avoids double bookkeeping across multiple tools, and often provides robust reporting capabilities. 

The trick to making this process work is making it as light-weight as possible to get all the data from the various feedback sources into it. If it’s burdensome to do so and it’s not kept up-to-date, it ends up being a waste of effort. Try having a designated person enter feedback data for different feedback sources and distributing the load across various stakeholders responsible for each source. 

Incorporate feedback into your product roadmap process

It’s critical to ensure you incorporate your feedback process directly into your product roadmap process to make the effort you put into cataloging feedback worthwhile. Roadmap planning meetings should always include discussions about  feedback received and whether that validates or pivots their current roadmap plans.

When discussioning what features to prioritize, having data-driven discussion with the team based on actual data inputs from feedback, knowing who is requesting a feature, whether you’re hearing it from multiple channels, and how frequently. This moves prioritization closer to actual user needs based on data and truth-seeking.

The value of the feedback is not simply the features users have requested, but the synthesis of the learnings from that feedback. For example, you might notice a request for functionality but then business strategy drives to understanding that the user segment is no longer a target customer. This synthesis of learnings from feedback is absolutely critical.  Over time as you get accustomed to leveraging your feedback and system of record and it will become a natural part of product roadmap discussions.

Agile

How I Prioritize

  • by marco

How I Prioritize

MARCO NESPECA

50% of my day

I spend most of my days trying to figure what the roadmap should look like based on a bunch of “stuff” I am continually collecting.  I call it stuff because there is so much of it and often it can start to look like it doesn’t make any sense.

In the past, my colleagues and I often discussed about a way to make this part of our responsibilities easier and more “concrete” or “scientific” (somehow) but eventually we agreed that this part of our job is more about interpretation and intuition than anything else.

We didn’t give up trying to put some logic into prioritization and finally agreed on the below aspects of this big part of our job which we try our best to apply everyday.

I categorize what influences our choices when planing our quarterly releases in 3 parts:

  • Customer/User
  • Business
  • Dream/Vision

Look at how I define these:

Customer / User

The customer is key right?  🙂  In my experience it depends…  A lot of times the customer isn’t the user but that’s a whole other story.  I always consider my customer as being the end user.

Feedback is what we look for when we look at this influencer and this is why I make a huge effort to get it directly from the user as this is what inspires me to feel that I am understanding their needs.  A great digital product must be customer obsessed and deliver value if we want it to succeed and to do this we have to find a consistent way of receiving and interpreting customer feedback.

Some of the methods I use are:

  • Analyze our own communication channels (Live chat, support emails, social, reviews, phone)
  • Analyze our competitors communication channels (Forums, social, reviews)
  • Email surveys
  • In-App feedback & polls
  • Speaking with customers regularly (Phone, presentations, webinars)
  • Understand our NPS

By doing the above I am trying to get an accurate understanding of our customer feedback in real-time, envision what their difficulties or feature requests are and build a matrix of frequency and occurrence to eventually engage directly with the customer about the collected details.  When I speak to the customer I outline the collected information and provide ideas about possible approaches to address their requests.  The feedback I collect is used when I plan quarterly roadmap releases.

At this point I can categorize and segment so as to attach value to these and I am finally ready to interpret what in the above illustrated effort would be best suited and best serve the customers needs and eventually include as a goal in my roadmap planning.

 

Business

Our job is about finding a way to get business and customer requirements to meet somewhere and bring value all-around. 

In business we ultimately want to drive profits by increasing and decreasing (resources) different factors and as a digital product we are aiming to: (SAAS)

  • Engage
  • Acquire
  • Monetize

We engage users and try to get them to use and re-use our product, by offering different and valuable features where our end goal is to retain the users we are engaging with.

By engaging with the users we are trying to be attractive and useful and pushing them to acquire and become an active user or bring them from being a user to being closer to a customer.

Finally we want to monetize by up-selling our users to our premium offerings, getting them to increase their spend, and preventing them from churning.

We must set our business KPI’s  and base them on business objectives, monitor them, look at how they change over time and use this data to better focus our efforts during quarterly release planning.

  • What is the long-term goal?
  • What seems like the easiest way to achieve this?
  • Where are the biggest business issues?

I make a list of OKR’s (Objectives and Key Results), set initiatives and desired change in specific metrics and try to estimate this realistically.  My initiatives are what I believe will help me reach my “Objectives” and my “Key Results” are my desired change in metrics for each of these initiatives.

Dream

Depending on the product stage we may have different types of “dreams or visions” for our digital product.  The vision we create depends on where we are in the product stage and basically attempts to draw a picture of where we want to go with our product in the long-term.  We plot this dream on our one year roadmap as a set of detailed feature descriptions that we eventually want to build into our product and update the status of each of these during our quarterly roadmap planning, verifying our progress or crediting/discrediting these basing our decisions on any validation work we’ve done since the last quarter meeting.

We work hard to guide our product goal on the understanding we have collected and adjust the roadmap based on these experiences.

In my current role, the Dream / Vision component of prioritization is often inline with the Business component and that is because the I am usually negotiating the quarterly releases with key stakeholders who in my case are c-level’s that are very keen on maximizing profits. (this correlation isn’t always true.)

The customer / user is usually guiding us to make changes to existing features so that they can better use our product to accomplish their goals “today”, which is good because it means they are interested in our digital product and truly believe they need it.

The fact is that all of the above influence the roadmap and prioritizing it isn’t so straightforward…

I often see that there is a convergence between what the customer is asking for and the product dream and when this happens I try to set the roadmap in the direction that will take us towards giving the customer what they want today and the product dream so as to include customer feature requests within our dream feature roll-out and considering that the dreams we have as an organization are mostly business driven this makes my life a little easier but it is crucial to continually monitor our 3 business factors: Engage, Acquire & Monetize. 

By keeping these 3 influencers in mind I can build, negotiate and get buyin on a roadmap that I can monitor over time, adjust if necessary and ultimately get results from.

Agile

What is an “MVP”?

  • by marco

What is an 'MVP'?

MARCO NESPECA

Understand the minimum

So… what do we mean by ‘MVP’?

The ‘Minimum viable product’ or ‘MVP’ can mean different things to different organisations and people but here is the definition of MVPs based on my personal experience.

Working “agile” to deliver modern digital products is essential because everybody wants to give the user something they will love and something that will give the user value.  To do this we must define an MVP during the earliest set of the product stage and plan a roll-out with the focus being the MVP and it’s goals as this will help us learn if what we are doing is what the user actually needs and if what we are doing is actually working.  This puts us a “learning” opportunity at an early stage so that we can improve the direction and methods at the earliest stage quickly and effectively reducing costs and waste.

The first question I ask myself when defining an MVP is “What is the users problem”?, then I try to build a use-case & experiment around this definition.  I am not talking about a huge concept or long term plan but “something”, a small thing that can easily be identified and tested directly with the user.   We should decide what our MVP is based on what we “believe” users & customers will appreciate as valuable, we basically put ourselves in their shoes and use our intuition & of course any data we have to define and release our MVP then move forward using feedback we collect from the actual users to continue building.  It’s essential that we be informed about the quality of what we are doing by the actual user, a real person and qualitative data.  Remember, our MVP isn’t anything near what our final product will be, we are “pinging” our user-base with the minimum and then moving forward fixing and iterating.

So how do we define this "thing"?

 

I like to approach it by looking at the end goal and then imaging how we can get there by building something small that resembles the “huge” idea we have and build it in a way that allows us to get valuable feedback.  This means that we must build a digital product that is real so that users can experiment and understand it as this is the only way we will ever be able to get to the next stage and integrate the best features in a way that the user will love.  Releasing something complex will only make it difficult for us to figure out what features are actually useful.  We do this everyday in our personal lives so why wouldn’t you apply this approach to your products and business?

I will super-simplify this… I like to cook and I love pasta and when I make a pasta dinner I go through different steps to get it perfect. 

  • I need to get the ingredients at the supermarket – I shop around, I squeeze and sniff the tomatoes, choose the best looking beef, etc..
  • I make the sauce – I add the ingredients one at a time, taste it at the various stages and adjust it.
Of course it is a little more complicated but we can simply say that an MVP needs to allow us to do the least and learn the most.
 

Simple concept delivery, observe, improve

 

Build your dreammap, break it down, identify the MVP and get something small infront of the user as fast as you can so that you can see how they use it, ask what they think of it, track their behavior and analyse all this stuff as quickly as you can at every iteration.  Identifying what proves or disproves your concept is the key to making sure your efforts are bringing value and reducing the risk of costly failure.

Remember to do this by releasing with a set of defined KPI’s and understand what metrics will be used to measure your success.

Digital Product Research

Building on Personas

  • by marco

Building on Personas

MARCO NESPECA

Who are we interacting with?

When I am introduced to the challenge of building or enhancing a digital product the first thing that I look to understand is who the user is.  Most of the time stakeholders are convinced on who their customers are and what they want but often when I ask to see they data collected about their users they don’t have much to hand over and what they do have is a bunch of numbers distributed across a variety of documents.

I want to talk about representing these numbers through a concept called Personas.

  • We need to know exactly who we are interacting with.
  • What are they trying to do?
  • What the current process & customer journey is.
  • Are there any other interactions touching other parts of the organization within the journey?
  • Why are they trying to do this through our digital product?
  • What brought them to use our product instead of another?
  • What is the users end goal?

The thing I am looking for here is more than simply a who but also why and how.  Understanding behavior in fact is what will help us guide the user through to conversion.

So whats so great about building and adopting Personas within an organization?

  • They help us better understand our customers.
  • They make us see things from the customers point of view.
  • Company-wide Persona acceptance forces the organization to approach things differently when making strategic decisions.

What you see here is a classic example of what I call a “traditional” Persona. (You can find in a Google search)

From a digital product perspective we can’t stop and be satisfied with the traditional Persona concept as these are limited to describing the customers attitudes or what influences them. 

What we want to do as Product Managers is understand the customers behavior.

What Product managers need for UX & CX

The questions we need answers to about the user are different and only these answers will give us insight to develop more usable and more valuable products for our users.

Firstly.. speak with the users by spending time with them whether that be in focus groups or controlled testing. 

There are other things we can do to better understand our users and there isn’t a “right” & “wrong” way to do it…  I think everyone should be creative but answer a few questions along the way.  Let’s look at them.

Story Cards

These should focus on what the user wants to accomplish and should not “speak” about the user but instead on their goals.

Here is an approach you can start with.

  • Make it short, 4 to 6 lines.
  • Make it simple.
  • Work with an actual user when you write it.
  • Tell about who the user is.
  • What they are trying to do?
  • What is their ultimate goal?
  • Each story card should end with bringing some value to the user.
  • Make sure it is a testable story.

With story cards we can eliminate traditional documentation and focus on the person’s functional desires.  We should have many cards for every user we encounter and in the end by creating many cards for each of our personas we will eventually have a detailed picture of what each of them is actually trying to achieve.

Empathy Maps

Use empathy maps to dive deeper into the user’s environment and focus more on goals and behavior and build on the personas. (Think of it as an extension of the persona)

Ask questions like:

  • What do they already know?
  • What do they want to know?
  • What else might our user be doing while using our product?
  • What are they trying to achieve?
  • What are they doing to achieve this?
  • Who is with the user while they are using our product?
  • What are the pain points and preoccupations?
  • How do they feel?
  • What does our product look like in their environment?
An Empathy Map:

Customer Journey Maps

Here is where we go from “looking” at our user and start focusing on our “customer” and what journey they take when engaging with our company and products.  As a customer our user takes different steps when interacting with our company and this makes journey mapping so valuable.  Over the journey, the customer will have different feelings, questions and ultimately may feel more or less comfortable with the interaction they are having through our product or with our company. 

Journey maps help us understand the change in attitude that our customers go through and this helps us make positive changes to the way we interact with them.

We should map the journeys as a series of steps and each step must contain a part of the total customer journey. Some questions you can ask when building your maps are: 

  • What part of the company or product are they interacting with? (Online, brick&mortar, social, phone)
  • What are they trying to do?
  • How do they feel during this journey?
  • Who are they interacting with at each step?

Try to keep them short but complete, these should be examples of “general” scenarios, no 2 users will ever have identical journeys but we are trying to get a general overview of what each of these could be.

This example says a lot about how simple a journey map can be and still be effective.