Creating and following a solid product management lifecycle is key to meeting your business’ objectives and therefore maximizing returns. It is essential for everyone in a senior leadership role within a business to understand the lifecycle and how that applies to what they do.

Within this text you will find the key elements in the Product Management Lifecycle, be able to understand why it is important and understand the key activities that will take place within each step of the lifecycle.

What is the Product Management Lifecycle?

The product management lifecycle covers all the steps in creating a product or offering, from identifying and collecting ideas to delivering a solution and driving adoption. The product management lifecycle is therefore not the product lifecycle which describes a product’s sales behaviour over the course of its commercialization.

The digram below shows the main steps in the product management lifecycle.

Principal Steps of the Product Management Lifecycle

Why a Product Management Lifecycle?

For most businesses, the investment in their products will be the biggest lever they have to drive their future success. Bringing the wrong products to market can mean disaster for a business, whereas getting it right can mean vastly exceeding targets and success for all stakeholders.

The goal, therefore, in having a product management lifecycle is to increase the chance of getting the right outcomes and reducing the probability of getting it wrong.

The lifecycle starts with ideas, which we call signals. Product managers have signals sent to them, often in the form of vague requests, and in addition they tend to be great at coming up with their own ideas on how to improve a product!

Given that the reality of every business is that there are more ideas than resources to develop them, there has to be a decision taken on what ideas will be developed further, and once that decision is taken, how to ensure a maximum of success.

For a business to navigate this well, they need a formal process that is:

• Transparent: all stakeholders need to understand what is occurring and why it is occurring.

• Agile: the process mustn’t add too much friction to innovation or cost too much to run, and must be able to adapt to rapid market changes.

• Effective: the outcomes from the process must drive innovation in the direction of business goals.

What are the main activities performed during the Product Management Lifecycle?

Many texts on Product Management focus heavily on the development step in the lifecycle, but there are many more activities to perform before, during and after that step. The following graphic gives an overview of these key steps:

Product Management Lifecycle with Principal Activities

The principal steps in the process are summarized below, with a link to individual articles explaining more about the activities and approaches for each one:

• Signals: Ideas for product improvement. We call these signals as they may the interesting or not, but are indicating there is something we should be paying attention to.

• Validation: Determine what signals should be a candidate for Development, investigate market demand and place in the roadmap or reject.

• Development: Find and develop a solution to the challenge posed in a candidate, test and build it.

• Go To Market: Launch your solution in the market place through experiments to test the solution and your organizational readiness.

• Adoption: Track your solution to make sure it is being used as expected by your targets and is meeting your commercial objectives.

Managing the Product Management Lifecycle

Like any important process in an organization, the product management lifecycle requires management, and software exists to enable that to happen in a more efficient way.

The market leaders in this space are ProductBoard and Aha, with ProductRoadmap being a value challenger.

Value Generation dashboard from ProductRoadmap

Managing a Candidate in ProductRoadmap

Header Image by Gary Bendig via Unsplash

Strong product management can lead to amazing performance for your business, supporting the work of all departments and giving you excellent returns on your investments.

However, it is a very difficult challenge to ensure that product is run optimally, and it can be difficult sometimes to identify disfunction in the race to release new value for the business.

To help you out, here is a list of ten indicators that your product organization has room to improve, and quick guidance on what to do.

1. Unclear Business Objectives

Does your product department know what your strategic business objectives are? Are they delivering according to what you believe your objectives to be?

Define OKRs (objectives with key results) that encapsulate your strategy for your product team. They must be clear and easily understandable; then share them with the rest of your business. The objectives that you define for product must also be aligned with those of the rest of your organization, notably sales and marketing.

Read more about strategic alignment

2. Squeaky Wheel Syndrome

Are there particular customers or internal stakeholders that seem to dominate the roadmap by making a lot of noise?

An example Roadmap from ProductRoadmap

Some customers are key to your business, and their supporters may be in a position to apply a lot of pressure to have their desired items on the roadmap. However, there is an opportunity cost to allowing them to dictate your roadmap where your teams might not be working on features that will allow you to attract new customers or better serve more broadly your existing base.

A key way to address squeaky-wheel syndrome is to ensure you have a strong and transparent scoring and prioritization system in place.

3. Customers are not Being Contacted

Are you hearing back from your customers that they feel disconnected from your product development strategy, that their voice is not being heard?

If this is the case, the main reason is that your product organization is not spending enough time on them, period. The first thing to do is to ensure your product managers have an OKR (objective and key result) to spend more time with customers.

Another complimentary approach is to restructure your team to create a clean differentiation between Product Owners and Product Managers. This will move the latter out of the day to day development activities and provide them with more time and headspace to spend with customers.

During the validation phase of the product management lifecycle, your product organization must be spending a lot time with your customers.

4. Where are your Prototypes?

If you are not seeing prototypes of new ideas before development starts in earnest, you can be sure your target customers aren’t seeing them either.

You want to make sure your investments in new features and products pay off, and that you reduce the risk of them not doing so. One of the best ways to do this is to prototype ideas and validate them internally and with customers

The development phase of the product management lifecycle must include the creation of prototypes.

5. “You mean no-one is using that?”

Have you spent months developing a new solution only to find out that no-one is using it?

This symptom speaks to many underlying causes. The principal one is that your product team is not creating the features that your customers want, in which case you need to review the signal, validation and development phases of your product management lifecycle.

On the other hand, this can also be symptomatic of issues in your GoToMarket and adoption phases.

6. Your Customers don’t know about a Feature

You hear from your customers that they don’t know about a new feature that you’ve spent a lot of time and money in developing.

There can be several reasons behind why this is happening, and frankly not all of them can be controlled by product. However, if the GoToMarket phase of the product management lifecycle has been implemented correctly, then customers should know. Some of the key issues are: not enough push to customers, lack of notifications to account management, lack of account management strategy to work with customers on the feature, ineffective marketing campaigns and not reaching the right people within customer organizations.

For SaaS platforms, consider using in-app notifications as one of your tactices to drive direct awareness on the user level.

7. Do you Know how Your Product Compares?

How clear is it within your organization how well your product drives value when compared with competitors or other substitute offerings?

To effectively market and sell a product or even a feature, your organization needs to have very clear positioning of the value of your product. If you see your organization working with feature lists rather than the value generating ideas, you know that you have a disfunction.

If your product, marketing or sales organizations struggle to speak in terms of value, consider implementing Jobs-To-Be-Done.

8. New Features Break when Given to Customers

Your customers are complaining that new features break or don’t address the value that was promised.

With the best will in the world, solutions that work fantastically internally, pass all their tests and meet the defined scope can have issues when being used by customers. Accept this risk and reduce it by making sure your product team rolls out new features gradually. Stop asking for big-bang launches, and ask for gradual rollouts to targeted customers or user segments. Consider this an extension of your experiment-based prototyping culture.

9. Delivery Dates have been Missed Again!

Product created a roadmap with dates, you shared it with your customers, sales was all excited and then…. nothing was delivered as expected.

I’m sure too you pushed for some items to be delivered more quickly? Here’s the thing with software development — it’s much more akin to artisan work than production line work. Most new features have new challenges that have a large element of risk. Either you pad your timelines to take account of this, or you change how your organization manages the roadmap.

Some organizations remove dates entirely from their roadmaps and just use a Now, Next, Later idea of timelines. A good middle route is to work with progressive timelines: This Month, Next Month, Third-Month, Next Quarter, Next Half and Next Year.

Example of using Progressive Timelines in Roadmaps

It’s important to note that any notion of time must be considered a target period in which the organization expects to begin *Go To Market*, but this is not a confirmed date for having a feature available.

10. Your Product Team is not Delivering Enough

You have all the activities in the Product Management Lifecycle, but your team is not delivering enough with the quality you expect.

Here’s the bottom line, you should have one product role per 8–10 developers. If your ratio is out, you will struggle to deliver quality across the Product Management Lifecycle. What are your teams not delivering on? Customer time, GoToMarket preparation, supporting engineering or supporting your sales teams?

In addition, make sure that your product teams are not involved in operational activities such as giving sales demos (sales should be capable of demoing themselves, either with specialized persons or preferably with each sales agent), making adjustments to customer accounts, doing deep dives on customer data or on bugs.

Learning More

If you want to learn more on how to optimize your Product Management Organization, walk through this series on the Product Management Lifecycle.

Header Image by Austin Distel via Unsplash

The final phase in the Product Management Cycle is the Adoption phase. Coming into this phase you should have a product or feature that has proven acceptability from its target customers or users and is ready to scale.

That doesn’t imply that the product or feature is perfect of course, but that you know:

• the solution is reliable and works as per the scope that was specified.

• sales are comfortable pitching and selling the product or the product with the solution.

• marketing is ready to take broad initiatives to communicate to customers and generate interest and demand.

• internal systems are ready to support the product or feature.

Once all of the above is in place and has been proven during the Go To Market phase, then the adoption phase is ready to proceed.

Objectives of Adoption

You have a moral duty to inform the market of a solution that can help them.

You’ve invested money, blood, sweat and tears in building a solution that will solve a problem and create value. You want to make an impact for your target market and help them improve their business. Now’s the moment where the rubber hits the road.

You have already defined a metric for the number of customers or users you want using your solution, now you go out and you achieve that metric.

Make Adoption work for You.

Fundamentally, you are either in a marketing driven business where marketing initiatives drive sales to new customers, or you are in a sales driven business where prospecting drives new customers.

In the marketing driven case, you’ll be spending a lot of time working with marketing and ensuring that their initiatives are producing the leads necessary and that the funnels in place are converting. You may have to continue tweaking messaging and positioning in order to achieve the results that you need.

Likewise, for sales-driven businesses, you will be continually getting feedback from the reps about what’s working and what’s not working; where they are getting push-back and where they are achieving success. Of course, sales will also be generating a lot of signals that are necessary to sell. Be very careful about monitoring the target lists and understanding how much progress is being made through these lists. If results are not what was expected, it’s likely that insufficient progress is being made in the lists.

Adoption Metrics

When defining the scope of the product, you should have defined adoption metrics. Now is the time to be compiling these on a regular basis and sharing them with your organization.

If adoption is not what you expected, you should be able to see this in your metrics. Don’t be afraid to ask your organization for help in understanding why thinks might not be going as well as you hoped. There could be good reasons that you can work together on to improve performance. It’s in everyone’s interest to monetize the investment that is made in new product and features!

Communicate to the Builders

Let your engineering and other teams involved in the development phase know how things are going and how what they have built is contributing to the success of your customers and the organization as a whole.

It’s essential for motivation that the fruits of one’s labour is viewed as valuable!

Header image by nrd via Unsplash

You’ve built your solution to address a problem or opportunity, and you’re proud of your baby and you want the world to see it! How do you go about getting it in the hands of your users?

In a word: slowly.

The Go To Market or Launch phase of the Product Development Cycle is concerned with taking a developed and tested solution, and getting it to the point where its commercialization or use can be scaled. This phase is essentially a huge preparation and test phase where the ultimate goal is to make sure that everything is in place across your organization to be able to deliver the solution to the world.

However, before the Go To Market phase can begin, there are certain key activities that should have been completed, in most cases during the development phase:

• Product Positioning: any changes that the new offering will make to overall product positioning.

• Support documentation & training: what does support need to know to support the new offering? Who will receive 1st, 2nd and 3rd line tickets? Will you apply additional prioritization to new tickets?

• Marketing Campaigns and Collateral: marketing should prepare and be ready to test their initial campaigns for the scaling of the new feature. This might mean producing multiple options to test with similar groups of customers or target customers.

• Sales Collateral & Training: updates to sales collateral and training should be prepared and ready to test.

• Self-serve Collateral: do you have FAQs or other self-support materials that need to be updated?

• Target Lists: which current customers will receive the new offering? Which target customers will receive marketing and sales calls and at what point?

• Metrics and KPIs: what will you be measuring to ensure that you’re ready to scale?

No to a Big Bang

We all get it, there’s lots of pressure to have a new offering released to all customers as soon as it’s ready. I mean, the code is ready so why not push it live to everyone right? And the customer is asking for it now, now, now.

Sometimes Big Bang releases work out alright — sometimes they are even necessary, but every time they are a big risk and the likelihood of something going wrong somewhere in the organization is really high.

Customers asking for something now will be upset when it goes wrong, or your support is not up to scratch. Sales will be burnt very quickly when they struggle to pitch a new feature or it doesn’t work reliably or as well as promised.

Yes to a Progressive Rollout

Go slow to go fast

This is what we are doing with a progressive rollout. It’s basically a period of testing to make sure that everything is working well before scaling a new feature across the full organization. During this phase a number of experiments will be made to build confidence in all of the items that were prepared during the development phase and to make sure that they are all working together cohesively.

Absolutely everything that has been produced for the Go To Market phase will be tweaked during this phase.

Here is a list of most of those items that you’ve been busy preparing:

Customer Target Lists

The heart of the rollout is the customer target list. Basically you want to select customers to rollout the new feature or product to. There can be two types of list depending upon the particular situation of the new product or feature:

• current customers that get the feature as part of their product suite — ie it has no additional cost

• customers that will have to pay extra for the product.

It is generally helpful to organize these lists into waves, starting small and selecting customers purposefully. Before selling into new customers, it makes sense to roll out to some existing customers to test the core of the offering before testing your sales approach and the core of the offering at the same time. In good science, one reduces the number of variables in every single test.

Within both lists, you want to select customers according to their particularities in order to get a representative cross-section of your customer base. For example, you may want to start with a low-volume customer and then move to a high-volume customer to make sure that the feature scales. Likewise, you may want to avoid customers that cause issues with support and account managers in the earliest waves.

Customers May need to Rollout too

Just to add a little bit of complexity, your customers may need to rollout new features within their organizations; provide training to their staff, adapt their business systems or their workflows. Moreover, your customers may need to build confidence themselves in the new feature!

If it is the case, choose your initial customers wisely and work with them during their rollout. Yes, it will take longer for you to get there, but every subsequent new customer will learn from those initial ones, and you’ll look like highly professional heroes (and who doesn’t want to be a hero?).

Your Solution will have Defects

Every new offering has some defects that only become apparent when customers start using it. Most of these defects will be minor and can be fixed relatively rapidly at a low cost. On the flip side, some defects might be so large that the new feature needs to be removed!

Small defects, bugs, should be fixed as soon as possible — identified bugs in new code should not be allowed to linger.

There will also be small niggles in the solution that only came to light now. These are different from defects in that they were not in the scope of the project. It takes a judgement call to decide whether or not they should be addressed immediately as fixing them will slow down your rollout and potentially impact other initiatives; or consider them as new signals.

Then there will be larger problems or opportunities that come to light. These should be entered into your Product Management tool as a new signal and follow your standard Product Management Cycle through a validation and prioritization phase.

Sales Laboratory

With a new product or a significant change to an existing offering, the sales organization will need to learn how to pitch it.

A demo and a new deck will not cut the mustard.

Sales needs time to learn how best to pitch the product, how to become comfortable in pitching it, how to figure out what questions to ask prospects during discovery to have them engage and all that fun stuff.

It’s suggested therefore to take a small number of the sales staff and have them experience with the pitch until they can tie it down to something that they are comfortable with. At this point, they can then train or at least provide support to the rest of the sales organization — at the very least you will have a success case to present within sales to get them amped-up and engaged.

Remember that with sales a significant proportion of their personal income can be on the line and that will generally make them wary or risk averse when introducing new products.

Marketing

Depending upon your product and organization, marketing might have a critical or more informational approach and role in your product rollout.

If you are relying on marketing to generate leads, they obviously need to test their lead generation strategies. Some of these strategies may not be applicable until the end of the Go To Market phase, when the software is ready to scale. For example, if blog or social media posts are part of that strategy, by their nature they can be hard to contain to specific customers.

Some strategies such as search ads to a landing page can be experimented with as volume can be turned on or off at any moment. This is also a great way to test out any tools that you may have created to help with adoption.

Internal Systems

Are all your internal systems supporting the new product or feature? Can you bill successfully? Can support create tickets and do they get to the right queue? Are you able to monitor uptake and adoption?

Metrics

Key to this phase are the metrics that have been defined and that you are following to ensure the success of your rollout. Are you getting the adoption you expected within your waves? Are users using the software as expected? Are you meeting the value generation that was expected?

Go To Market is Cross Functional and Complicated

Reading this list of items to take into account, you may have realized that it will require a lot of coordination and communication between different groups in the business, particularly with sales and marketing, support and engineering.

Yet it should also be evident to all that taking a considered rollout approach will better position the product and the organization to scale a higher quality solution, more effectively and with a faster market penetration.

Remember to keep your Progress Up to Date

It’s important to provide transparency on the progress in rolling out to all of your stakeholders; reporting on successes and learnings throughout the process and progress through the waves.

Your Product Management Tool should be able to provide you with the ability to capture this progress and make it available.

As an example, here is how Product Roadmap enables you to give an indication of progress and provide comments.

Indicate Go To Market Progress using the slider in Product Roadmap

Adding comments on an Initiative can provide useful feedback in Product Roadmap.

And Finally…

The slow and steady tortoise wins the race.

Header image by Ben Wong on Unsplash.

When you’ve identified a problem to solve or an opportunity to address, how should you go about developing the best solution? What are the key things that you have to bear in mind?

Coming into the development phase of the Product Management lifecycle, you have a candidate that has been validated and prioritized. Hence it has become an initiative and will be in an ordered backlog with other initiatives. Given that it will soon be worked on, here are the key steps that can be expected to occur during the development phase. Please note that this article will not go into the details of development methods such as Agile Scrum or Kanban; only touching lightly upon them where necessary.

Scoping

A scope document will need to be produced by the product manager. The principal goal of the scope document is to inform all parties from engineering to support to account management what is being developed and why. Hence it must not be overly technical, it is not a specifications document and should be kept relatively brief.

Coming into the process, this document will provide:

• a description of request that was made,
• the problem that needs to be solved or the opportunity that needs to be addressed, and
• the value that would be generated if a solution is found and implemented.

As the development phase continues, the scope document will also be updated with:

• a high level overview of the solution, and
• key metrics that will be followed to indicate that the initiative is a success.

Developing a Solution

Solutions will generally be developed with a cross-functional team that heavily includes engineering and probably some UX:UI in the software space. Depending upon the extent of the problem, it may be necessary to bring in more stakeholders, especially with problems that can be expected to have a solution that is tightly coupled to another group.

During solution development, there are really three main phases:

• Solution design and prototyping
• Development
• Testing

Solution Design and Design Sprints

For certain problems, the design sprint can be a great way to generate a solution. Without wanting to go into great detail here, the idea is to go from problem to prototype within a week in order to quickly generate and confirm a solution.

This works well for certain problems that are not overly complex, are large enough to merit the investment and will have good buy-in from stakeholders.

Solutions and Prototypes

Designing the solution is generally done in strong collaboration with engineering. Product’s role is not to come with a 100% baked idea, but starting from the value that needs to be generated, they should come with ideas that can be refined with engineering and UX.

It’s possible that multiple valid solutions are generated, and these can be tested during the prototype phase.

It’s worth bearing in mind the words of Sir Karl Popper when looking to find the best solution, and using this moment in the process to challenge and have challenged those solution we have proposed:

“The point is that whenever we propose a solution to a problem, we ought to try as hard as we can to overthrow our solution, rather than defend it.”

Prototyping

Why Prototype? Isn’t it a waste of time and resources? Prototyping allows us principally to manage risk. Building a solution that doesn’t meet the needs of customers is a huge and expensive waste. While prototypes never get to production and are thrown away, their value is based around increasing the probability that the initiative will be successful.

The amount invested in a prototype should therefore be relevant to the overall size of the initiative. There are different ways of creating prototypes:

• Mock-ups: perhaps the easiest and most common prototype are mock-ups of what the solution will look like. Using tools such as inVision, these can be made clickable to demonstrate application flow and make it seem more real.
• Videos: another generally low-cost prototype is the video that can demonstrate how a solution will work. This can be useful to show more complex end to end interactions.
• Coded Prototype: requiring more investment, but a good option where there is significant risk and/or there is a desire to have stakeholders actually work through a solution. A coded prototype is an application that is not production quality code, will not handle errors well, will use a set of test data and won’t generally require tests. It can be updated quickly with learnings from interactions with stakeholders.

As you can see, prototyping can go from cost effective to complete, depending upon the complexity of the initiative — in any case there is little reason for not going through this step.

Solution Build

With learnings from the prototype, the Product Manager can complete the creation of epics and stories that the engineering team will require to build out the solution. Within the initiative, which is often represented by one or more epics, it is important to correctly prioritize the different stories. If a significant risk or difficulty has been identified during the solution design, this should be prioritized early in the process to ensure it can be overcome and to prevent perceived delays later in the process.

As often as is possible, engineering should share their progress with product and demonstrate what they have accomplished. It’s important to identify any issues or devisions from scope and design as early as possible in the process.

From the product side, it’s also essential to be able to report back to the rest of the organization the progress that is being made on the initiative. This can be done simply by counting up progress through stories, but is often better to combine story count with an idea of the size to get to a percentage complete.

Non-Engineering Work

During the development phase, there is not just work to be done by engineering, there is also a lot of preparation that needs to be completed in collaboration with other teams.

This is all part of the development process in order to be ready for the next phase.

• Support: what does support need to know to help customers with the new solution? Does any existing material need to be updated? Is there any new material that needs to be added?
• Sales: have they identified target customers that would be attracted by the new solution? What changes do they need to make to their sales process? What new questions need to be asked to customers during the discovery process? Is positioning worked out? What updates are required to sales collateral?
• Marketing: how will marketing promote the new feature? Are they working with sales to target the right businesses? Have they considered the standard updates to release notes and the business website?
• Account Management: which existing customers will be offered the new solution first? How will it be pitched to them?
• Legal: are there any changes that need to be made to terms and conditions or other impacts due to the solution?

Solution Testing

There are several different ways that the solution will need to be tested before it is really to be used by customers.

Most of the testing of the solution as defined should be done within the development team, either by a dedicated QA resource or by the developers. Development should not be handing-off code that is not functioning as expected.

In more complex cases, however, it is essential to perform more complex integration testing to make sure that all is working as expected and that the feature will scale to the size of the largest accounts.

Features with an important UX:UI change must be tested by the UX:UI designer before being considered complete. It’s important that the vision of the designer has been implemented correctly and that the delivery is cohesive and works. Often what works on “paper” needs tweaking when the final delivery is made. Moreover, it’s also important that the UX:UI professional can improve their skills through reviewing the implementation of what they have designed.

Tracking Development

Development phases can take a significant amount of time and will leave most stakeholders at a minimum curious about the progress or requiring to know when deliveries will be made in order to coordinate their work.

In most organizations, product leaders need to provide updates on a regular basis to executive or cross-functional committees. Tracking progress is across all initiatives and indeed candidates is not a simple affair, and reporting in a way that people understand is not obvious.

Using tools can help. In Product Roadmap for example, each candidate and initiative enables progress to be tracked across multiple steps and is then rolled-up into one percentage complete number.

View Progress on the Candidate or Initiative level

Mean Progress rolled-up on the Candidate and Initiative Level

Header image by Chris Gower from Unsplash

The validation phase of the Product Management Lifecycle is one of its most critical steps. Without solid validation, a business can spend scarce resources developing the wrong offering and missing opportunities in the market. Suffice it to say that many business failures occur due to poor validation.

Validation of a signal (an idea for a new feature or offering) will begin once that signal and been deemed a candidate for validation. A well structured signal will contain some concept of:

• what is being requested,
• the problem or opportunity the signal is expected to solve, and
• the value that addressing that problem or opportunity will generate.

This concept will be further investigated during the validation phase.

What is the goal of Validating a Candidate?

There are multiple objectives in validating a candidate. The outcomes from this process are:

• Ensure that the problem has been well defined and that the value to be generated is well defined. Value should be captured quantitively where possible, for example, by saving 4 hours per transaction on average.
• Understanding who would benefit from the candidate? What proportion of current customers and prospects.
• Trying to measure the revenue and profit impact for your business, especially if it appears that a large investment will be necessary.
• Understanding what strategic benefits can accrue from the candidate. For example, does it increase barriers to exit for adopting customers.

Note that during the validation phase we not not trying to validate the solution for the candidate, indeed at this point we do not and should not even have a solution.

The Size of a Candidate

Understanding the expected size of a candidate is important at this stage uniquely to evaluate how much validation should be done. However, it is not recommended to go much beyond a very small, small, medium, large or very large scale — given the nature of the solution is unknown, moving beyond this would be non-sensical.

For example, if the candidate is addressing small changes to the offering, for example adding fields into a form, it may not be sensible to invest much in the validation effort. If, on the other hand, the investment is sizeable, a new module is required, then more validation should be done.

The product manager should apply good judgement and be prepared to defend why they have chosen what level of validation, and what tools is use during the the validation.

Validation Methods

There are many methods that can be used to validate candidates. The product manager should select those that are appropriate. For certain methods, it may make sense to bundle validation efforts across multiple candidates.

The appropriate validation methods will also depend heavily upon the type and size of your business. If you’re B2C versus B2B, whether you have a very large or small client-base, what kind of clients and verticals you are servicing.

• Client calls: reach out to a representative selection of your clients to understand how a candidate may impact their business. It may make sense too to bundle multiple candidates together when discussing to make the most use of their time. It’s essential to go in well planned and make sure you get an idea of the value a candidate can generate. Can you also get a quantitive idea? Note that for interviews, it’s recommended to reach out to a minimum of five customers, however eight to ten is great and twenty is fantastic.
• Target-business calls: for some candidates, the goal will be to expand the business out to new market segments or new geographies. In this case, you would want to reach out to these target-businesses in those markets to investigate the value of the candidate. Note that it is not recommended to reach out to business currently in the sales cycle to avoid disrupting that cycle and the messaging from the sales organization.
• Surveys: surveys are great when you have a larger number of clients, or have several relatively low value candidates that you want to get a rough idea of value. When you ask about interest in a candidate, don’t just ask clients whether they are interested in the idea, ask them on a scale of 0 to 10 how much difference a candidate would make to their business. You should also ask for free-form comments.
• Customer Advisory Boards: having a customer advisory board is a great way of assembling your key clients and enabling them to discuss together your candidates. Oftentimes the discussions between clients will enable you to go even further down value discovery than with just one client.
• Focus Groups: similar to customer advisory boards, can you get together a set of target users to discuss the candidate or a set of candidates to get their feedback?
• Data: what data can you get from your systems that could indicate whether a certain new feature might be highly valuable? This can be flows through the application, time spent doing activities that you could remove (and thus put a dollar value on) etc. Data from systems is probably the principal way of determining value for B2C offerings.
• External Data: what industry trend data can you use to show the value of a candidate or on the other hand show that a candidate has little value?
• Short business case: at this point, if the candidate is looking like it will require a significant investment, it might make sense to do a back of the envelope style business case to understand what is the potential financial outcome.

Validation Outcomes

Once the validation process has been completed, write it up in a short report — try to keep it to one page so that it can be easy consumed by stakeholders. Use of the validation outcomes to work through the scoring and prioritization process to understand how important this particular candidate it and where it will fit in amongst the initiatives that are currently being worked upon.

Indeed, the validation exercise may lead to the conclusion that any further work on this candidate is not warranted.

In case it does, it’s essential to tie back the validation to the objectives introduced in earlier in this article.

Value Metrics

Coming out of validation, it should be possible to determine initial success metrics for the candidate, in order to answer in a quantitive way “what does success for this candidate look like.” Depending on the feature, it could be a number of uses per month, it could be financial gain, time saved etc.

Ideally, it would be possible to tie the metric back to direct success at the client. The client saved or generated a certain amount of money — however this is often difficult to calculate directly without significant investment and participation by a client and they are unlikely to find this worth their while. Hence, look for a proxy figure to represent this in your metrics.

You may be asking whether it’s not too early to be defining these metrics. The answer is a resounding no — thinking through metrics will confirm whether you can understood the value that the candidate is expected to generate, and you’ll need your metrics defined as you go into the solution phase of the product management lifecycle.

The Story

Whilst not mentioned as an explicit outcome, by the time the validation phase is complete, you should in a position to tell a story about why the candidate is valuable.

Hence, be in a position to say if we do this, it will have this outcome for the customer and therefore that outcome for our business.

Conclusion

Running a validation process is the key part of the product management lifecycle. It must focus on understanding value and preferably being able to quantify it.

Without great validation, it’s hard to run a successful Scoring and Prioritization process.

Header image from Kenny Luo at Unsplash

Prioritizing the work to be done in a small business can make the difference between business failure and success. Build the wrong thing, and there can be no second chances, build the right thing and you make a huge difference to the business.

Many small businesses have many competing demands for their available resources. These can come from customers that can be too big to lose, changes in the market place, opportunities, that extra feature you need to close a sale…. how do you decide between all of these different competing demands? And worse, how do you avoid switching between different initiatives and never really bringing any to completion?

The Product Management Lifecycle

At this point it’s worth reviewing the Product Management Lifecycle and understanding how Signals and Candidates play their part.

Product Management Lifecycle

• Signals: Ideas for product improvement. We call these signals as they may be interesting or not, but are indicating there is something we should be paying attention to.
• Validation: Determine what signals should be a candidate for Development.
• Development: Find and develop a solution to the challenge posed in a candidate.
• Go To Market: Launch your solution in the market place. Adoption: Track your solution to make sure it is being used as expected by your targets.

Strategic Planning Theory

Without wanting to go into a lot of detail around strategic planning, it’s important to have in mind the basic elements of that theory. Without some modicum of strategy, strong prioritization becomes exceedingly difficult.

There are different frameworks that exist to help with strategic planning, such as the Lean Canvas or those from MBA programmes that look at internal and external factors. What they all tend to have in common is the analysis of what a business can do well, with what’s happening in the markets it serves and then understanding where there is opportunity — so called “blue water” with little competition, and determining where the business is strong.

The ideal markets will enable it to tackle a problem that is currently not being tackled well or at all, where you can erect barriers to entry & exit, and where you have the capabilities internally to execute well.

As an example, think of the Apple iPod. Apple was not the first digital music player on the market, but they were able to create a better product both in hardware terms and software terms, bring their power to create an online Music Store which created barriers to exit; and they had the competence internally to execute well.

When one looks at our own business, what should come out of the strategic planning session is a strong notion of what the principle strategic goals of the company are. They may be to break into new geographic or vertical markets, they may be to increase penetration of an existing one, they may be to increase customer satisfaction and decrease churn, they may be to reduce costs and be more operationally sound, or to increase integration with customers. The objectives of every business will be different, and they are likely to change overtime. However at any one particular point, you should have about four to six key goals.

These goals are absolutely essential to the prioritization process as they are what a candidate must be considered against.

What to do if You Have no Clear Objectives?

In my considered option, a Product Manager cannot do their job of prioritizing new features and offerings if they does not have clear objectives to prioritize against. Otherwise they are just blindly throwing mud against the wall and hoping some of it sticks.

If you don’t have objectives, then ask for them! If your executive team is unable to provide them (and there can be many good reasons for this), then determine yourself what you believe the objectives should be, share them with the executive team, and let them know this is what you will be prioritizing against. I am sure that will spur them to action!

Scoring and Prioritizing Backlog Candidates

Once you have your set of objectives, you can apply them to your idea candidates and hence prioritize your list. Let’s say that you have a set of objectives:

• Increase revenue
• Improve market position
• Increase efficiency
• Increase customer value

Every candidate can then be scored against each of these objectives on a scale of 1–5. For example, in an earlier article, an example was given of a new report that was requested. This request can then be scored as:

• Increase revenue-1
• Improve market position-2
• Increase efficiency-0
• Increase customer value-3

Giving a total of 6 points. Naturally, the candidate will then be sorted against all other candidates who may have higher or lower scores.

The Weaknesses in Scoring

There are weaknesses in this approach, clearly. In an ideal world, every candidate would be subject to a financial analysis that would indicate the expected revenue generated. For small businesses however, the costs and loss of agility would make this approach unfeasible.

Also there is some level of judgement that is required in attributing the correct score on each point. It is recommended that the scoring be done in a small cross-functional committee with representatives from the executive body, engineering, sales and customer success, as well as product. That is also a great way to get buy-in across the board and provide a high-level of transparency.

How to Manage Scoring

Scoring ideally would be done in a specialist tool that enables this, such as ProductRoadmap or ProductBoard. While spreadsheets can be used for this function, they do not scale well and it can be difficult to track discussions and why different decisions were made.

Within ProductRoadmap for example, each candidate can be scored: Scoring in ProductRoadmap

Candidates can be sorted by score: Candidate List

And you can provide feedback to Signal creators on the value that their ideas and opportunity assessment has generated for the business. Value created by a reporter in ProductRoadmap

Header image by Element 5 Digital via Unsplash

Small businesses need to be really good at product management. They need capitalize on their flexibility, yet make sure that they are exercising their resources in the best way possible — there is little room for error.

The Product Management lifecycle begins with Signals, and they are one of the most crucial parts of the whole process. This article will review the importance of Signals, the need for businesses to have a structured way to capture signals and provide some valuable tips for how to go about it.

Signals and the Product Management Lifecycle

At this point it’s worth reviewing the Product Management Lifecycle and understanding how Signals play their part.

Product Management Lifecycle

• Signals: Ideas for product improvement. We call these signals as they may be interesting or not, but are indicating there is something we should be paying attention to.
• Validation: Determine what signals should be a candidate for Development.
• Development: Find and develop a solution to the challenge posed in a candidate.
• Go To Market: Launch your solution in the market place.
• Adoption: Track your solution to make sure it is being used as expected by your targets.

What is a Signal?

“A signal is any idea or concept that could conceivably improve your offering.”

That is it as a definition and it is purposely simplistic. It does not at this point consider whether or not an idea is good, or whether or not it should be worked on. Some ideas are obviously misguided from their conception, some are fantastic no-brainers; but the majority live in a grey-area in between.

Signals can come from many different sources. The obvious ones are: sales, customer success, account managers, partners, support & development. However, one should also consider other sources such as: industry experts, blog posts, government and competition.

Why Collect and Process Signals?

Wherever a signal comes from, what you must be aiming to do though is collect as many as possible, and “process” as any as possible. Collecting all this information provides your business with a long term collection of industry intelligence, and a track of how you’ve considered that in the past.

A key outcome of collecting signals is the ability to see where and how they cluster. So if you have multiple customers requesting the same thing, you can start quantifying that and understanding that it’s a potentially good improvement to your offering. On the other hand, if you have also previously rejected a signal, you can help your organization present consistent and rapid feedback to the client on why this is something you would not consider.

Working a Signal

Typically when you receive a signal, it’s likely to be very simplistic in its nature: “Customer X wants widget Y.” For a Product Manager, this is clearly not enough, so it’s really important to dig further into the request. Every signal should be “worked” to ensure it has:

• Problem/Opportunity: what problem is addressed if this signal is implemented? That can also be an opportunity that is addressed.
• Value: what value is created for the stakeholders(s) (customers, internally) is the signal is implemented.

Until these two key items are understood, a signal should not be considered ready to have a decision taken on it.

Value is particularly important. As Product Managers, this is inherently what we exist to generate, so we fundamentally must get to the bottom of the value that a Signal can potentially create. Without this, we’re taking blind decisions and are likely to create solutions that do not fundamentally address the underlining need that has led to the creation of the signal. Jobs-To-be-Done is a fantastic concept to use in order to get to this value.

Example of a Signal Let us take the scenario where a client has requested a new report. This signal needs to be captured, along with the customer who has requested it, and then it needs to be worked to understand the value the report is expected to generate. Thus:

• Description: client wants a report of when their data is updated.
• Problem to Solve: client is not sure that the data they have in the system is up to date.
• Value to Drive: clients having age of data means that the client can appear more reliable to their customers. Clients found that lacking this reliability led to 15% of their churn.

The Signal at this point is rather simple, however to get to this point multiple discovery discussions are often held within a company and with clients.

Tooling and Methods to Collect Signals

There is no silver bullet tool that will automate the process of working Signals, and neither should there be. It’s important that this process of working Signals is done as a conversation in a collaborative fashion. It’s very rare that a requestor will provide a clear definition of the Problem to Solve or the Value to Drive.

Internal Product Roundtable

Signals can be generated at any moment, or they can be harvested at appropriate moments. Here are some ideas that can help generate signals for your business:

Internal:

• Round tables with representatives from different departments. You could do this weekly, monthly or quarterly.
• Open up a Slack channel where product ideas can be shared. The great thing about Slack is it’s easy to have a conversation with parties participating when they can.
• Product open hours — publish a time where your door is always open and anyone can swing by.
• Send a survey: regular surveys can push people to share their ideas. If you do survey, it’s important to share the results too!

External:

• Set up meetings with a representative set of clients to ask what they need more from your product.
• Survey clients who you can’t talk with directly.
• Use in-app tools such as Pendo to ask for feedback — this is often a good opportunity to combine with NPS requests.
• Set up a Customer Advisory Board to discuss with your key clients.
• Listen and participate in Quarterly reviews.
• Subscribe to the key blogs in your industry (you can have their RSS feeds pushed into Slack).

Once you have identified how to get new Signals, you need to put them somewhere. Using spreadsheet solutions such as Google Docs quickly becomes overwhelming and doesn’t scale well; especially as more people use them.

Luckily, there are some great Product management solutions available such as ProductBoard, AHA or ProductRoadmap that will enable you to easily capture signals. ProductRoadmap has a nice chat-style interface so you can provide it directly to your customer-facing teams and it will give them feedback on the value that their captured Signals have generated for the business.

Collecting a Signal in ProductRoadmap

List of Signals in ProductRoadmap

Header Image from Studio BCN via Unsplash