How to Take Your Digital Strategy Beyond Marketing and Into Product Development


Let’s talk about digital strategy and why you need one

If you have no clue what digital strategy is, you’re not alone.  Most of the froth around digital strategy centers around marketing, but there is no commonly accepted definition of digital strategy.  So, I will provide one for you.  Digital strategy is “The marriage of strategic insights and technology-based tactics in a digital first world.”  “Digital First”, in a business sense, describes how technology impacts everything about how products are envisioned, developed, marketed, monetized, and consumed.

Having a digital strategy is important because it gives you a stable approach to a changing technology landscape, and it provides a framework to experiment with new execution models while maintaining alignment with strategic goals.


Digital tools and technologies continue to change; Create stability with a disciplined approach

Its a fine line to walk:  Following all the latest digital trends means companies can chase unproven digital technologies down a rabbit hole.  Anyone remember QR codes?  But waiting too long means attempting to catch up in what may be an already saturated space, such as Microsoft and Amazon’s ill-fated attempts to gain traction in the mobile phone market.  Having a digital strategy means having the ability to test, integrate, prove, and ultimately scale new digital tools (and products) in line with their business impact.

In 2000 there was no mobile app ecosystem, there was no Facebook, there was no Twitter, there was no Pinterest, there was no Instagram.  In the last 10 years the arrival of these new tools has created unprecedented opportunities for companies who were able to test these tools, measure their impact, and integrate them into how they do business.  Unfortunately, most digital strategies have nowhere near this level of sophistication and are short sighted


Why most digital strategies are incomplete and what to do about it

  • Most companies don’t have a digital strategy.  They try new tools and techniques in a very ad-hoc way with limited support, sloppy measurement, and unorganized scaling strategy
  • Most digital strategies are silo’d in marketing.  Companies agonize about how to get more “engagement” and “brand mentions”; overfeeding the marketing monster while starving their innovation and product development machines.
  • Most digital strategies do not include product development.  Product development is the “last mile” in your digital strategy.  Whats the point of high brand engagement and 2 way conversations if you can’t convert that knowledge and engagement into products you can sell to customers?


Make sure the digital strategy budget has room for technology and technologists

Allocate 30% of your digital strategy toward the exploration, development, and use of new digital tools.  Create a “team within a team” by embedding a small cross functional product development team in your digital strategy group to rapidly prototype and release products.  This team needs to be separate from corporate IT so they are 100% aligned with the goals of the digital strategy team and don’t have the inertia of existing structures to constrain them

When marketing has an idea, the cross functional product team should be able to work digital strategy to design, build, test, market, launch and measure new product ROI in a matter of weeks.  This will let you codify the process with fewer hand-offs and test hypotheses more quickly.


Look for product ideas hidden in marketing conversations

With all the customer engagement you have, make sure you’re listening.  Often new products and services that customers are willing to pay for are hidden in those conversations.  Follow #hashtags and catalog the kinds of information you see.  Look for conversations about your competitors saying things like, “I wish they could…”, or “It would be awesome if…”, or even “It sucks that they wont….”


When initiatives show promise, scale up

Creating a digital strategy that includes product development means that when a new approach shows promise in key areas, you can scale it up quickly.  Your product development team can operationalize the approach and transition it to corporate IT while they continue to push the edge finding new techniques and tools to evaluate and measure.


Our digital future

The tempo of our digital drumbeat increases every year.  Companies who don’t see themselves as digital first will lose ground as consumer expectations evolve in lock-step with technology availability.  Companies who continue to divorce their strategy from their digital and technology strategy will muddle through, always in reactive mode, and companies who adopt a disciplined yet flexible approach to digital will be able to manage the uncertainty and change.  Welcome to the revolution.

Get More Product Content

Until Next Time,

Stay Agile, My Friends


There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Why Requirements Refinement Should Be An Ongoing Process


The year, 1998.  The place, some nameless IT office.  A young man is preparing for his first day of work.  He has no idea what a business analyst does, but he knows it has something to do with computers and will mean gainful employment for him.  His mentor sits him down and says, “Are you familiar with IEEE 830.”  He was not.  The mentor begins an intense interpretive reading session,

“1.2)  The system shall allow a user to buy a cake with a credit card
1.2.1)  The system shall accept Visa, Mastercard, and American Express
1.2.2)  The system shall charge the credit card before the cake is made
1.2.3)  The system shall give the user an order number…..zzzzZZZzzzzzzzZ”


Things have changed a lot since 1998

IEEE Standard 830 was last updated in 1998.  The internet was in it’s infancy, mobile phones were used to make calls and calls only, and your 17 year old nephew was a newborn.

In the meantime, the development of software has become more complex and more connected, while business costs and competition have increased.  Michael E. Porter of the Harvard Business Review writes, “… new types of products alter industry structure and the nature of competition, exposing companies to new competitive opportunities and threats.”  If you created the requirements for a 5 year program in 2006, there is a sea-change of events you could not have accounted for.  IEEE 830 was created in a time where you wrote requirements once and only once, and put a great deal of effort into “getting it right the first time”, because you didn’t have to worry about the industry being upended by the time the project was completed.

In the last 17 years, we have learned a lot about software projects and specifically requirements.  Namely:  Its very difficult to get them right the first time, up front.  If we know they wont all be right the first time up front, then we need a mechanism to constantly assess requirements against our original hypothesis and new information.  This is where ongoing requirements refinement comes into play.


Helps keep other supporting documentation up to date

A bad side effect of “nailing down” requirements up front is that we create reams of documentation the quickly begins to rot.  Meanwhile, the analyst who was engaged with the project for the first 6 weeks during the requirements phase has moved on and no one wants to take on the task of updating requirements, lest they be saddled with that duty forevermore.  Since the documentation is out of date, no one reads it.  Since no one reads it, it rots faster.  After a few months of this, the *real* information is in people’s heads (and in the code), and the requirements documentation is for suckers and newbies.

If requirements were revisited every 2 weeks on a cycle, it would be much easier for them to keep up with code changes, because we would only have to incorporate 10 business days of “new stuff” into the requirements.


Helps continuously align requirements to business priorities

One of the reasons the software changes after it has been spec’d is because there are emergent business priorities and opportunities that don’t care that the requirements have already been signed off.  One example of this is McKinsey’s article (full disclosure:  I’m a McKinsey alum)  that describes Amazon’s advanced customer segmentation, a technique that has only become available in recent years because of the explosion of online interactions and data processing capabilities.

A “rolling wave” of requirements refinement would allow an “opening” to re-prioritize emergent needs against existing requirements, allowing us to take advantage of innovations in mobile, analytics and cloud.  Of course, this is heavily dependent on the requirements being prioritized to begin with.  But that is another story for another day.

Until Next Time,

Stay Agile, My Friends

PS, Go here to get my “5 Signals A Requirement Should Be Deleted” tips

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Why The Best Product Managers Delete More Than They Add


The product was falling under its own weight.  It was bloated and didn’t really solve a key problem for the customer.  I talked to the lead product manager about some of the issues with the product, and he relayed that the previous product manager pushed the team to add these features.  He was looking for the “one magical feature” that would make the product take off and make him the hero.  Unfortunately, this approach of “Throw stuff at the wall and see what sticks” is an incredibly poor way to manage a product.  In reality, product managers should deleting more features than they add.



Most features are never used

You can probably think of a common software product you use, and the percentage of its features you use.  Most of us, even power users, use only a small subset of the features of a product.  The Standish Group reports that “only about 20% of a software product’s features are used ‘Always or Often.'”  This means that 80% of the features in the product are never touched.  However those features still need to be supported by the company, debugged by the teams, and pumped up by marketing.  Unfortunately, its the natural state of inertia that as a product is on the market longer, it becomes more and more “feature rich.”  If these features don’t add any value to the user, then they are wasteful.


Effective product management = the art of saying “no”

When a product is first envisoned and built, its easy to manage.  You take an idea and iterate on it with your customers.  However, after a product gets traction, managing it becomes more difficult because there are more outside influences.

  • Certain segments of customers want to see features added to a product that might not be part of the overall strategy.
  • Executive leadership wants to see other features in a product.
  • Competitors are adding features that you need to react to.
  • Product management has their own vision and roadmap.

All these factors combined makes it difficult to decide what goes in and what goes out of a product.  Weak product owners say yes to everything, and simply add it to the list.  Strong product owners stay true to the vision and strategy and say no to most requests, keeping the proposed feature list in line with the overall strategy.  This is, in essence, the root of effective product management.


Removing features creates simple and elegant products

All complex products evolved from simple products that worked well.  Its just along the way, these products lost the original focus, leading to bloat.  Simple products have a much higher chance of inspiring customer passion and delight.  Ask any serious hunter if he would ever use a Swiss Army knife.  He will laugh.  A Swiss Army knife is a tool that fulfills many functions in a mediocre manner, while a knife made for the purpose of skinning animals performs beautifully, even though doesn’t have a nail clipper attachment.  What kind of products do you want to make?  Swiss army knives with nail clipper attachments?  Or highly functional simple, effective tools that customers find indispensable?

To take products back to their simple, elegant, functional roots, remove extra features that don’t add any value and, focus on the core “brand promise”, and create a limited yet necessary feature set.

Until Next Time,

Stay Agile, My Friends

Get 5 Tips to Know When You Should Delete a Requirement

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More