Product Pondering

Recently I keep coming back to the distinction between innovation and invention.  In technology, it’s always important to keep this distinction in mind.

For an extended treatment of this topic, I recommend a well-aged post on Scott Sehlhorst’s TynerBlain on Product Managers and Innovation.

Product managers are responsible for the commercial success of their offerings.  For sustained commercial success, it’s often necessary to keep pushing the envelope and solving problems better than competitors.

That’s where innovation comes in.  Innovation is, as I describe it, devising a better way to solve a known problem.  Invention, on the other hand, is devising a new way to do something, regardless of its commercial implications.

Both of these can lead to commercial success, but in my experience, starting with the business outcome (job to be done, or problem to solve) in mind is more likely to lead to success.

While it’s true, and I frequently state, that “one can invent anything, but it doesn’t mean that invention will be useful” - it’s also true that sometimes, invention for its own sake is commercially viable.  

In Scott Sehlhorst’s post, there are a couple of other well known examples.  

A researcher discovers an adhesive that is not strong enough for tape – but can be used over and over – and we have sticky-notes.....

Another fun example to think about – the light bulb.  Did Mr. Edison start with a market problem (candles are not a good solution to “see stuff at night”) and end up with a light bulb?  Or did he start with an invention (distributable electricity as a service), and try and “invent” a market use?  I never met the guy :), but my hunch is the latter.....

Google is famously known for their “twenty percent time” – which gave us GMail and Google News.  

Most of us aren’t fortunate enough to work in enterprises where we can grant engineers 20% of their work hours to work on pet projects in the hope that they will be commercially viable.

Product management, in a way, exists as a function due to the difficulty and the need to apply limited resources to develop commercially viable solutions to problems that--in Pragmatic Institute’s words--are urgent, pervasive, and people will pay to solve.

The first VP of Engineering I worked with was known to say “This isn’t a research project, people.  We need to launch!”  

Once, long ago, I conducted a brief interview with Jon Gatrell of Pragmatic Marketing.  

OpenView Partners published an ebook called ‘Build’ last year, evangelizing the product-led approach to growth and sharing success stories.

OpenView kicks off the ebook stating “We believe that #Product Led Growth (PLG) is the future of SaaS.”  

OpenView defines PLG this way: “Product Led Growth (PLG) is an end user-focused growth model that relies on the product itself as the primary driver of customer acquisition, conversion and expansion.”

The book is broken into four core sections: Acquisition, Conversion, Success and Extras. Each section includes a set of independent case studies / interviews of SaaS success stories.  

This post captures key lessons from the Acquisition section.

I recommend this talk I just watched by Dan Olsen, providing a primer on thinking about metrics in relation to product.  

He includes Dave McClure’s AARRR (acquisition, activation, retention, referrals, and revenue) and his own simplified model for evaluating metrics and optimizing them.  More notes on his website.  Enjoy!

In the middle of a brainstorm I created this quick sketch of the relationship between product management and product marketing.  

It covers but one trip around the “infinity” symbol, as all these activities are ongoing at all times--a quick attempt to show how these functions work together.

Once upon a time, I wrote a thing.

In the early 2010s, I was an active blogger on the topic of product management. As part of my process of learning my craft, I participated in a loud debate among the online product management community which was trying to define the difference between the agile product owner role and true business product management.

My thinking at the time, partly shaped by the organization I was in, led me to advocate a top-down approach where a product manager drives the roadmap and outward facing activities, in partnership with a product owner who is more focused on development activities and backlog management.

I was invited to share a post on the blog of Aha!, a provider of product management roadmapping software. I found out a few years later from Aha!‘s CEO, Brian De Haff, that this post was among the top performing posts on the Aha! blog.

And here it is: The Product Manager vs. Product Owner

As a postscript, I must confess that my view has now changed.

Having seen the flaws of this model, I now advocate narrower full-stack product roles, where individuals own both the outward and inward facing activities. The issue of product manager overload is better managed with via breadth of responsibility. Brian took a similar position in his rebuttal.

What do you think?

Earlier in my product career, I developed a blog called ‘The PM Vision’ that I recently shuttered.

One of the most valuable pieces of content on that blog is an interview I conducted of Rich Mironov. We discussed ProductCamp as well as Rich’s thoughts on roles in product management.

Rich was a great sport while I fumbled through the questions here, providing helpful information for product practitioners. Rather than keep this buried on my Google Drive, I decided it’s time to share this with the public once again.

Enjoy!

I wrote a thing.

I’ve been at the product management game since 2007, when I started my product career as a product analyst / product owner for what was then called Kodak Dental Systems.

In the twelve years since, much of which I’ve been involved with the ProductCamp unconference movement, I have learned a ton about product management, and about the ways other product people come up to speed.

My post is an attempt to catalog and summarize the many different ways product managers can learn more about their craft; and the value to be found in each approach.

So without further adieu, here is the Brief Guide to Product Management Certification and Training!

In June of 2012, I gave a presentation to the PMI Agile Interest Group in Atlanta about my team’s journey from using the Scrum methodology to more of a Scrumban process.

Why move to scrumban?

Anecdotally, Scrum is the most popular agile methodology, however kanban and variants have grown in popularity over the years. In 2012, my team ran into frustrations that drove us to adapt. In the years since, I’ve recognized that some teams start with scrum and then adapt as they mature; but at the time, this was a novel discovery.

Back then, three items emerged in repeated retrospectives that led us to shift gears:

First, the additional stress around completing stories on the scrum board by the last day to avoid “failure.” Along with the pressure of solving new problems in the course of true R&D style development, the team felt pressured to (1) take shortcuts to complete work early enough, and (2) shortcut testing to close the story and claim the points. Regardless of the percentage of stories completed by sprint’s end, we determined that the average velocity over most three-sprint periods remained roughly the same.

Second, the team spent a full day or more (out of 10) doing detailed tasking, in order to come up with estimates that led to incomplete stories and stress at the end. We also recognized that when starting a new story mid-sprint, we’d have to revisit the initial conversations anyway, when details were invariably forgotten. Also, based on the previous bullet, that the reliability of the projections wasn’t high to begin with.

Third, with a group of stories to complete, each team member started on a different story at the same time, which prevented collaboration and led to lack of focus.

What was the result?

Based on all of the above, we decided to abandon the first-day tasking sessions and do the detailed planning for stories just-in-time. This means things only moved across the scrum board when action was wrapping up, not in advance of when we predicted action would tak eplace. Further, we decided to only start one story per pair, when the pair was ready to work on it.

We were no longer following the scrum methodology.

This we determined was what many call “scrumban,” a blend of the timeboxed ritual of scrum with the flow of kanban. This meant we maintained the iteration barriers, biweekly demos, standups, and retrospectives that we conducted with scrum in order to retain transparency and visibility. Because biweekly demos kept happening, the fact that the mindset was vastly different wasn’t immediately obvious to other stakeholders, but what we stressed was meeting deliverable dates.

The team responded well to a clearly painted vision and a target date, as long as it was reasonable. The team did not respond well to being chastised for failing to complete specific stories in specific sprints which were not tied to a release.

Does Product Management Care Which Agile Process Is Used?

On one hand, product management is responsible for defining products that will succeed in the market–not for choosing how they are built. Yet, an agile discovery and delivery process offers more opportunity for discovery and for course correction.

Selecting which agile methodology is less impactful to product management than whether to be agile at all. However, in the context of scrum vs. scrum ban, I found that Product Management can manage agile better under Scrumban than Scrum, especially when there’s a single person serving as product manager and product owner.

This is because there’s less time-sensitivity around the product owner’s need to be present “in the room” with engineering. Product owners had more flexibility to book customer calls / visits and could tag-team with development to “be ready” when the next epic required their input.

More specifically, with robust engineering practices around test-driven-development and especially behavioral-driven-development, the product owner’s information was captured during story elaboration when a feature is started. The team thinks through all the scenarios and details one or more stories to support them, with all scenarios for each story captured in structured behavioral commands. (Gherkin).

The team then gets to work and calls the product owner when the software is able to pass those specifications–and obviously, when questions come up. This process allows ample time for the product owner to engage in expectations management throughout the organization, requirements gathering, customer development, and all the other fun things a product manager is responsible for…..like meetings 🙂

The PO needs to be available to see stories demonstrated once they’re ready for the “Done” column – and to answer questions when they come up.

Long term, velocity improved in the aggregate by about 20% as the team found the cadence more conducive to flow.. That also makes Product Management happy!

There are of course other factors involved–such as maturity of the team; presence or absence of dependencies between teams; presence or absence of a scrum master; etc. But with all things equal, and with a team mature enough to handle it, a less prescriptive model is helpful for some teams.

See the slide presentation on Slideshare here

Originally posted on The PM Vision (now defunct). This version has been edited for clarity.

The Perils of Short-Term Vision

Product managers have access to limited development capacity but infinite requests for features.

It’s important to solve the most important problems first; once priority is established, it becomes critical to understand the problem and then deliver a solution.

Too many teams struggle to build effective solutions once the next “most important” item is chosen. They solve the wrong problem. They address the correct problem with an ineffective solution. The solution requires rework once the next need is considered.

Dual-track Agile is a way to solve those problems.

Which of the following problems have you encountered?

Agile product teams don’t think beyond the next couple of features.

Agile development teams think one feature at a time, and do extensive rework when a subsequent feature changes the implications of the previous.

Solutions aren’t vetted with customers or stakeholders until after code is written, presumably using the “minimal marketable” version of a given feature.

When a team is ready to work on something new, engineers have to spend precious time defining and understanding the need.

Alternately, if a solution is proposed, engineers begin to analyze the poorly thought through idea that is brought to them to build, and waste cycles getting answers and devising a better solution.

Subsequently, there are sales and prospect expectations to reset.

Once the capability is released, other needs that stack upon the first result in rethink and rework. This is the dreaded refactoring that people frequently consider to be engineering’s way of wasting of time, but which is often the result of building things without thinking them through first.

That said, because the teams haven’t planned very far in advance, at least there aren’t long term plans to rework when Sales kicks over several new features that “we have to include in the contract” to win a deal in the intermediate term.

There is a better way.. but it requires a shift in thinking in both product and client negotiations.

What is Dual-Track Agile?

Via Marty Cagan, I became acquainted with Jeff Patton’s concept of “Dual-Track Scrum.” I use the term “Agile” to be more inclusive of other agile methodologies like kanban, scrumban, etc.

Dual-track is an organizational structure separating the effort to deliver working software from the effort to understand user needs and discover the best solution.

It is only by iterating through a number of options that the best solution can be identified and “discovered.”

Refactoring is natural when you’re pivoting; when you’re making earth-shaking discoveries about your market and their needs.

However, if you’re building product for a known market, offering a product with a fairly well understood shape, and still experiencing frequent refactoring, you probably aren’t putting enough effort into product discovery.

How does this work in practice?

Each track is given a general mandate: discover new needs, or deliver working software.

Taking the baton first, the Discovery track is responsible for validating hypotheses about solving user problems, and preparing user stories for the Delivery track. This means the Discovery track is learning about users in depth, analyzing feature requests, and drilling down on high priority needs.

Here’s how we executed this at The Network [now part of NAVEX Global]:

Step 1: is that the Product Manager provides a prioritized list of user needs & feature requests and helps to explain the need for each.

Step 2: the Discovery track generates an understanding of requirements, wireframes and — using a series of Design ‘N Architecture (DNA) meetings to answer technical questions — architectural approach. This is executed by a three-part team: the Product Owner, the User Experience lead, and an architect from Development–similar to the Product Owner Team that some companies employ more formally. (The Product Manager is involved for us at this point, generally for the purpose of elaborating on the need and providing feedback concepts generated by the Discovery track.)

Step 3: the Delivery track is responsible for delivering working software each iteration. They take the artifacts generated in the Discovery track and creating the detailed user stories required to deliver on those ideas with acceptance criteria; and for delivering the working software. The Product Owner guides this through the process with little involvement from the Product Manager except for checkins. This gives the Product Manager time to interface with clients and client-facing teams.

Early lesson learned: ensure someone from the delivery team is involved during discovery, or you may create an unintended waterfall handoff that isn’t pleasant.

What is Discovery, exactly?

Discovery is a form of purposeful iteration on solution options. Designers create solution approaches from the needs brought to the team by Product Management.

The Product Owner, Business Analyst and User Experience representatives whiteboard wireframes and talk through happy path and edge cases to see if a design holds water. When it doesn’t, changes are made and the cycle repeats.

Simple features may require only a few iterations; more complex ones may be iterated on for several weeks off and on, woven in with other responsibilities.

Seems tedious? It is.

But it sure beats releasing software only to find that something wasn’t considered.

When the team is confident in the design, it’s put in front of others. Members of client facing teams are invited to a walk-through, and advisory board clients are recruited to provide feedback.

For critically important features, everyone’s feedback is considered and the design meets all known concerns.

Compared to a process where features were built using the first design that came to mind and little critical review, this greatly improved the confidence in deliverables from the rest of the business and drove better outcomes in a short time.

What’s the time horizon of Discovery?

In our organization, we struggled with understanding the time horizon of Discovery. There are two sides to this discussion.

Long term first

For existing products in market that are feature-poor compared to competitors, especially in a mature market, you may have a fairly clear understanding of what the product will look like in the future. In these cases, it’s sensible to do a Story Mapping exercise to paint a picture of all the key functionality, so that you can craft a sensible plan for how to get there in the most advantageous way.

During a catch up exercise, mapping out which needed features will have the biggest impact can buy you time to build more nuanced features, and in some cases eliminate or greatly reduce the need for others.

At this stage you can think about things like taxonomy, mental model, and other core concepts that allow you to organize and structure the application optimally. You can also think about how big components will fit together, and break up capabilities in a corresponding fashion, to expedite development and to ensure future features have a place to fit in the application structure with little to no retrofitting.

Discovery focuses on those high-ROI items in order to get them built out first. This is how you “catch up” when there are a lot of gaps.

Short term first

At the same time, client requests may be coming in. You’ve got existing clients with pain points, and prospects demanding certain gaps be closed contractually. Therefore, to meet business needs, the Product Manager likely has high priority needs mapped out on the roadmap, and is pushing to have Discovery around those items conducted first.

Ideally, if you’ve done enough Long term discovery, you have considered how some of the short term needs will be met, and you have an idea of where in the framework they would be built.

Depending on timeline, in order to meet contractual requirements, you may need to work on some features prior than is ideal. Here you’re hoping to do enough discovery and to be able to construct them with as little risk to the core direction as possible.

The risk in this approach is you build features that don’t account for the fundamental pieces you know you need, and find yourself performing refactoring when it’s time to build them in a more sustainable fashion. This requires balance.

Product owners are responsible for release targets, so they’re thinking in terms of specific functionality to be delivered within a given timeframe.

This process has encouraged another opposing point of view: Imagine what the world will look like with the problem completely solved, and then schedule which parts of that solution to build in the time available.

It requires some mental gymnastics, but implementing such a process can result in noticeable payoff.

We found that while navigating the chaos of current client needs, this process encouraged us to find opportunities to address multiple needs with a single effort. Bigger ROI for the same time investment.

Buy-in can be a challenge.

Skeptical coworkers may not be convinced until they see the impact of features that have gone through a robust dual-track process and until you clearly illustrate the tangible impact of decisions you make now on needs that weren’t expected to be addressed quite so quickly.

How does Discovery affect Product Outcomes?

Discovery minimizes refactoring.

As we discovered, spending enough time on discovery prior to building software helped ensure we thought things through properly.

Sometimes it feels excruciating.

You have gone over this already. But now someone wants to look at it from what feels like a 37th perspective. So you walk through it again.

And you notice something.

So you make a tweak to your design.

Unbeknownst to you, that tweak saved you a week of refactoring–or even an emergency patch–that you would’ve had to perform had that design flaw made it into production.

If you’re solving a brand new market problem that no-one has solved yet, you may not be able to think about things from 37 different points of view.

But if you’re going into a crowded space, or solving additional problems for a market you know extremely well, you are doing yourself a disservice if you don’t think things through early on.

Even if you’re agile, when you’re building feature upon feature, flaws included in the core functionality become expensive when you discover them later.

And “we didn’t think of that” is still a flaw even if you weren’t “supposed to.”

Those weeks of refactoring are a direct drag on speed.

Discovery increases developer confidence.

Another impact of Discovery that I’ve personally observed is an increase in engineering confidence.

Developers, as a group, ask a lot of questions.

Developing a system from nothing requires a deep level of analysis most ordinary people can’t fathom.

This puts a good deal of pressure on a mere mortal product owner.

One of the product owner’s primary tasks is to be available to answer development team questions.

Many of those questions are simple. “What label should this button have on it?” “Why would someone fill out this form?”

But even more are not.

“What should happen when someone tries to submit this form but leaves the SSN empty?” “What happens if the patient’s status is discharged when the form is submitted?”

Developers love to explore edge cases.

And their confidence decreases the more times the product owner has to say “I don’t know” and speak with stakeholders.

Confidence grows when the product owner knows what she wants, and is able to communicate it concisely.

That knowledge comes from having thought things through beforehand.

The discovery process is where that detailed analysis takes place.

Isn’t this just Waterfall?

One of the primary concerns I had when I first encountered the approach was that with so much pre-work, I sensed the smell of waterfall.

But that was only an early concern.

We were still able to shift as new information was learned. In fact, Dual-track encouraged us to learn new information.

Business priorities still took the lead.

The reason it smelled like waterfall, in my opinion, is that we were too agile. Because we assumed we didn’t know what was coming next, we resisted doing too much thinking ahead.

But in scenarios where a product offering has clear gaps against competitors in a defined market, that wasn’t true. We do know what we need.

We might not know what’s coming next.

But even that wasn’t true.

Given that we know where the product needs to be, we have a pretty good idea at a high level of what to build in what order to satisfy future needs.

We don’t know what the next prospect will ask for.

We had to learn to communicate why staying on the current path is–in some cases–better than chasing the shiny object.

But we still required the freedom to chase the object when appropriate.

Dual-Track didn’t stop our business agility. But it did make us think twice about changing directions, which in our case I believe was healthy.

How does Dual-Track Agile benefit Product Managers?

It should be clear from the above points that outcomes driven through dual-track are often better solutions to customer pain points than without such a process, and tend to require less rework.

I observed in one anecdote about implementing dual-track Scrum that the Product team drove the change:

I think it’s important to note that the driver for wanting to adopt Dual-Track Scrum came from the product team. This is the way they wanted to work, and I and the other delivery managers helped the product team bring this change into the company.

This isn’t a “development” change. It’s a driver of business value.

Much as I’ve suggested that the business needs Product Management to be Agile, product management is the beneficiary of better solution discovery, so they should be pushing for it–whether it’s Dual Track or something else.

In dual-track agile, the same investment of time is more impactful linearly and indirectly.

I’m hoping to see in my current environment over time that having Discovery finished when a feature is ready to be built consistently drives faster Delivery. So far I’ve seen that in one instance but I cannot claim a trend.

Originally published on The PM Vision [now defunct].

Product teams exist to assess opportunity and capitalize.

Product managers are tasked with finding market problems that are urgent, pervasive within a certain target market, and that people are willing to pay to remedy. Once found, product owners guide the development of a profitable solution to those problems. (at smaller organizations, or for new product initiatives, those duties may be owned by the same person)

Market problems can be solved with new service offerings; new features; new partnerships; or new products. Given limited resources, however, product teams can’t pursue every opportunity. They must prioritize.

In traditional corporate environments, teams conducted extensive research prior to starting a product effort. The business case served to document the context, rationale and revenue potential of a business opportunity.

Over time, it’s been proven that this snapshot of the world is out of date as soon as it’s “completed,” and builds expectations for the solution as-currently-imagined such that pivoting based on market response becomes difficult. While some teams take a truly iterative, lean approach to product development, there are still quite a few who still need to assess the opportunity ahead of time; but there is room to utilize to a more concise opportunity assessment.

Three Approaches to Product Opportunity Assessment

The more significant the investment needed to develop a proposed solution, the more detailed the assessment should be.

Large organizations answering to PE or to Wall Street need to demonstrate profitable use of capital; they’re not rolling the dice. They invest in only the promising opportunities.

In order to invest in only the most promising opportunities, it pays to start working through the sequence of assessment techniques until you’re comfortable the investment decision. The bigger the opportunity, the more thorough the technique, generally speaking.

The three methods I propose in ascending order of thoroughness are:

Scoring (most applicable for features in an existing product)

Opportunity Assessment (big features or small products)

Prototype / Minimum Viable Product (full size products)

Scoring

The quickest assessment technique is to evaluate your idea according to a weighted scoring formula built into an easy-to-access spreadsheet. This tactic allows ideas to be quickly ranked against each other.

There are several versions of the prioritization spreadsheet -- and methods that include RICE (Reach / Impact / Confidence / Effort) and MoSCoW (Must, Should, Could and Won’t) -- but they all align around quantifying an idea on a number of metrics and using a weighted formula to rank them.  

These approaches are often enough to prioritize enhancements to existing products.

My friend Jason Brett has shared the 60 Second Business Case , which is my favorite of these quick spreadsheet methods:

Jason’s approach maps to an existing customer base and product in market, supporting operational necessities as well as thresholds for scoring projected revenue impact. The headings can be modified to apply the evaluation technique to the needs of any product organization.

Scoring opportunities allows a team to quickly focus on ideas worth pursuing, and to filter the rest out.

Opportunity Assessment

For ideas that past the first screen, and for those ideas suggesting larger features or a new product altogether, a slightly more involved opportunity assessment may be warranted. Marty Cagan suggests that answers to the following ten questions should comprise the assessment of a product opportunity:

Exactly what problem will this solve? (value proposition)

For whom do we solve that problem? (target market) / (user and buyer personas)

How big is the opportunity? (market size)

What alternatives are out there? (competitive landscape)

Why are we best suited to pursue this? (our differentiator) / (Do we need to partner?)

Why now? (market window)

How will we get this product to market? (go-to-market strategy)

How will we measure success/make money from this product? (metrics/revenue strategy)

What factors are critical to success? (solution requirements)

Given the above, what’s the recommendation? (go or no-go)

This information forms the basis of a business model canvas or lean canvas as part of assessing the opportunity as well, and considering the business strategy stalwart, the SWOT. (or a Product Canvas!) The canvas should include key elements like:

Solution – To elaborate on solution requirements, include a short description of the solution itself to keep everyone on the same page.

Weaknesses – A standard prompt from the SWOT: What things that we aren’t good at should we consider?

Threats – This one might overlap part of Porter’s 5 forces: Is this an easy market for others to enter?

In some cases, to clearly communicate the product idea being considered, a rough sketch of the solution is useful. A visual illustration of the product concept in wireframes, along with a list of key workflows, can ensure meeting of the minds. This is particularly important when this assessment is to be shared within a team.

Prototype / MVP

In a Lean Startup, market testing a proposed product idea at a very early stage offers the opportunity for early learning from that market testing, and then adapting based on the learning. For product concepts that address unsolved problems in new markets, this is another tangible step on the road toward commercialization.

Some questions–such as how much someone will pay, and whether a product workflow matches actual business process–may not be truly answerable until a potential customer can evaluate a prototype in their own hands.

In this sense, it may actually not be possible to evaluate an opportunity without some sort of MVP--whether it’s software or not.

Startups

Startups–essentially funded experiments working to find a business model for a new offering–can use the same techniques.

Because their purpose is to experiment and not to be profitable immediately, startups often follow an initial hunch which looks like a basic opportunity assessment, and build an initial product that is offered for sale. (The MVP)

Iteration, rapid development and learning become key, while struggling through the first few customers until enough customers are won to declare product/market fit.

The initial assessment helps frame the MVP and iteration by clarifying where the market is and how big the problem is. The assessment and MVP, in this case, aren’t intended to “prove” profitability as they might be (mis)used in an Enterprise product company. They are intended to discover new markets.

Conclusions and Rule of Thumb

Use the opportunity assessment to try to prove that a given market problem does NOT provide a viable opportunity. There could be many reasons, including:

Perhaps there isn’t a big enough market segment

Perhaps the opportunity doesn’t offer enough revenue potential

Perhaps the opportunity does not line up with your organization’s strengths/strategy.

In any case, it may not make sense to build an MVP; or it may make sense to revise the proposal (pivot) before building anything. If, instead, your results suggest there may be something there, you have one or more hypotheses to test with an MVP!

My general rule of thumb is:

Do as much due diligence as is appropriate for the investment you’re considering.

A quick check of the wind direction might be enough to validate your decision to prioritize features of a product already in market. For a new product opportunity, you’ll want to conduct a more thorough opportunity assessment, in case there are reasons you shouldn’t go forward to the prototype / MVP stage….that will allow you to invest instead in a more promising idea.