API Strategy - How to develop a API strategy ?

API’s are essential component of a platform & apps ecosystem.  However, many companies look at APIs as an afterthought. Especially, the established Enterprise vendors.  The standard response (which I’m sure you are familiar with) by a software vendor who hasn't put a thoughtful API design is ...Yes. We have a bunch of APIs which enable you to do anything we do through standard interfaces. Just give us a buzz and we will get you started with a $ services engagement for custom development. Such vendors are slowly disappearing and are getting replaced by tech start-ups with innovative solutions and standards based API support, SDK’s , API applications to configure , build or extend the base software / services or the platform easily. These vendors focus on answers to five key questions to help shape up their API strategy :

 

  • What is the business purpose and the intended audience of the API?
  • What type of functionality & interfaces should the APIs expose?
  • What is the community & support framework?
  • What is the GTM model ?
  • What is the API governance model?

Sharing a few simple thoughts and a framework to help develop and API strategy . As always, I’ll go the basics to define a framework for the API strategy. Lets start with the definition :

API: An interface designed to accept a broad class of apps in ways that allow app developers to use the platform’s capabilities without having to concern themselves with how those capabilities are implemented in the platform (src : Tiwana, Amrit (2013-11-12). Platform Ecosystems: Aligning Architecture, Governance, and Strategy)

API Reference Framework: This is a high level framework that focuses on the five key questions listed above. It’s a conceptual model that should aid the evolution of the API design strategy.  

The most important component of this framework is - API types. One should think long and hard enough on this topic - Why APIs & For Whom? This decision/strategy dictates every downstream activity and things will automatically flow if you get this right.

Everyone calls themselves a software platform. Are they really a platform ?


Lately, I have been working on defining what is a software platform. What characteristics a software ecosystem should have to be called a platform . Every vendor that builds and sells software calls itself a platform.  So what differentiates a app , a product, a service vendor from a platform vendor.  Capturing some ideas to help identify a platform company or develop a platform strategy. Lets start with the basics :


  • Platform - Codebase of a software system that provides capabilities that are shared by apps that interoperate with it along with the interfaces through which they operate.
  • Apps - A software module or a plug-in or a sub system that connects to the platform to add and expose capabilities
  • Architecture - A blueprint that describes the entire ecosystem which comprises of the platform, the apps, the interfaces used by the apps to connect and integrate with the platform.


If one asks for a list of platform players the usual suspects come to the forefront - Amazon, Google, Apple, eBay, Facebook, Android.  However, if you look deeply these vendors didn't start out as a platform. They were all standalone services that subsequently over time got transformed into a platform by doing something special - adding complementors . These complementors produced mini software ecosystems that augmented the capabilities of the core platform. E.g iOS has app developers, Kindle has eBook publishers, Google has advertisers etc.  The companies that failed to make this transition did not last long - Blackberry, Kodak, Nokia, Palm etc. This defines the first and the most important characteristic of the platform - multi-sided . There should be at least two distinct groups that interact with each other using the platform . A relatively simple analysis of the top software players highlights some other characteristics of a platform . Here are a few critical ones :


  • Network effects : Facebook or linkedin or uber is a prime example. They all follow Metcalfe’s law
  • Lock-in : These platforms are sticky. Competition is so high that you keep adding “stuff” to discourage the users from opting out. E.g Uber
  • Envelopment : Platforms players over time start to envelope capabilities of other platforms. E.g Android phones offering cool camera capabilities
  • Greater than one side with multiples for the top three characteristics : The most important attribute.  E.g’s Travel sites with users like us and airlines on the other side - there are network effects for airlines & end users , there are features that make the whole experience sticky  and there are capabilities being added to provide a holistic travel experience such as vacation packages which are disrupting an entire industry. Amazon’s book publishing business , Apple’s music business, all peer to peer collaborative consumption companies like Airbnb , Kickstarter etc reflect the multipliers for network effects, lockin and envelopment on every side of a multi-sided platform.
One could go on and on with examples of platforms and what defines them. This is a summarized list of some of the key attributes to help you identify a platform vs a product/ service/ app player and also shape up your platform strategy . 

How do you build a high performing product management team?


How do you build a high performing product management team?

One can pick up a best selling leadership book and identity the key attributes that results in high performing teams. I don’t need to outline the same in this blog. Instead, I'll focus on what hiring managers need to work on to form a "PM team of highly motivated individuals".  Have categorized this process in three parts :

Part I - Hiring the right people

This is no different then defining the right  product. Recall in , the difference between building the product right vs building the right product in my earlier blog . So, first and foremost ...you need to "find the right PM " for your team.  I had written a blog earlier that focusses on key qualities of a product managers .  These qualities are essential for the PM job.  Quote from Mary Kay Ash helps illustrate the kind of PM you need to hire. She stated that there are four kinds of people :

Those who make things happen
Those who watch things happen
Those who wonder what happened
Those who don’t know that anything happened!

Product Managers ought to make things happen .  They need to be really really smart and also have crazy passion not just for the technology/ product  but also the  company and its core values/culture.  Believe me this translates into the product definition.  You will find many examples of vendors who have PMs who believe in this mantra - Why do services from Google look and feel and act the same way...even the acquisitions. 

Louis V. Gerstner was once asked what do you want people to do.  He answered…

Hire ‘Action’ oriented employees. –  “Win, execute and team.”
  • “WIN:    It was vital that all the IBMers understand that business is a competitive activity. In the new IBM there would be no place for anyone who lacked zeal for the contest.”
  • “EXECUTE:         No more studying things to death. In the new IBM, successful people would commit to getting things done – fast and effectively.”
  • “TEAM: This was a commitment to acting as one IBM, plain and simple.”

Part II - Forming the team of product managers

Once you have the right people you need to start working on the next thing - forming a team. I'm not going to suggest any team building exercises here.  I'm assuming that you have already tested the individual to see if he is a team player and can fit into your company culture. So, what’s next...

Next step is focused on making sure the individuals understand that "marketplace is the driving force behind the company and the products".  As a manager you need to establish a training program that could be anywhere between 8-12 weeks and is focused on helping the PM understand the :

Training program : 8-12 weeks

Focus
Purpose
Market Analysis
Competitive Analysis
Customer Analysis
Understand the dynamics of the industry/customers/ competitors
Understand Product / Technology
Conduct a mini POC on their own or join the pre sales team for a deep dive POC. PMs need to know every single aspect of the product and also the sales cycle (technical + business conversations)
Customer Visits
Understand end users/ industry/ product usage
Economics of the product
Understand the P&L model of the product, financial performance, trends etc.

I cannot emphasize how important it is for the PM to visit a few key customers/partners who use the product but also install , configure your own products  or conduct a real POC.  Prior to starting in the job , product managers should go through a very through understanding of these areas. As a hiring manager you need to facilitate and oversee this program with real deliverables  at the end of the program.

Part III - Managing the team

Managers have their own preferences for managing the team.  Styles vary from complete control to total autonomy.  However, for product management roles I have a slightly skewed perspective. There is only one product manager for every product (usually). Having a right person for this job is crucial else you waste costly cycles, loose customers and create unnecessary stress within the cross functional team. If you have a wrong person for this job then you need to correct the situation asap.  You cannot micro manage in this position and if you do so then you don’t have the right person for this job.

Louis Gerstener once said...i manage by principle , not procedure.  I'd recommend to hiring managers to establish a set of guiding principles for the team.  Key principles in my opinion are :

  • Need to setup up intense and demanding goals - PM's job is not for everyone.  PMs need to be challenged with demanding goals
  • Measure performance based on talent, hard work and accomplishments - you have to measure success with real metrics.
  • Invite Debates
  • Can do attitude - Folks need to make things happen and not watch and debate things happening  (Louis G)
  • Accountability
  • Fearless about disrupting the status quo  - Should be willing to speak openly and honestly
  • Drive experimentation

Once you find the right person, establish the principles you need to step out. Micromanaging the PM does not help at all. This is an important job where you need to give autonomy to the individual for him/her to be successful . 

Prioritization of Requirements - Right product that delivers maximum value


Prioritization of Requirements - Right product that delivers maximum value

This is one of the most important decision a product manager has to make in order to define the release and develop a roadmap.  Even though this is a key decision...very few  PMs spend time on this process .

The most common way to prioritize requirements is by adding a suffix with every requirement that states it’s a must have, should have and nice to have. So, what's wrong with us method of prioritization.  Must have in PM's definition implies that we wont ship the product, should have if we have time in the release and nice to have is essentially relying on some unknown factors influenced by super natural powers to get the requirement into a release.  Natural reaction on the first look at this list is for the engineering teams to eliminate should haves and nice to haves. Why do teams do that? If you recall in my previous blog on what's wrong with PRDs I highlighted that engineering cannot cost the release by reading a few lines/paragraphs. So, the natural reaction is reduce the risk by eliminating what' s not really important to the Product Managers to begin with.  Should have's and nice to have's are gone in the very first discussion or prior to that. Then what remains are the must haves and the "dance" starts.  Engineering is asked to provide scoping analysis of the high items  and the process of elimination starts.  An engineering lead I'm friends with started a presentation with a nursery rhyme as part of his discussion with the product managers:

  • You put your right foot in,
  • You put your right foot out,
  • You put your right foot in.
  • And you shake it all about.
  • You do the Hokey-Pokey,
  • And you turn yourself around.
  • That's what it's all about!

After all this is...what remains is a set of requirements that for legacy Enterprise products are usually the "me too" or "customer escalation" or " a specific customer request" or a "catch up" or "close gap" or a "tactical feature" to deliver the release. At times, innovative requirements/features do get it but this is based on perception of the PM and no hard data and thus starts the costly gamble for the product team/business.  You may or may not get lucky with these innovative requirements.  Similar issues, exists with all the other forms of prioritization - p1, p2 p3/ 1,2,3/ voting etc.

So, what's the alternative…

Let's revisit the core responsibility of a product manager again . Product Managers have to define a right product that provides maximum value to the customers while reducing the complexity and meeting the time to market needs of the business and customers.   With this key definition firmed up...lets look at the prioritization process from this perspective in the diagram below. Always, keep this definition in sight ...


  1. Business Strategy - What is the strategic direction of your business?
  1. Product Strategy - > How will you support the business strategy?
  1. Business Opp. Assessment -> What Problems?, For Who? Competitive/Substitutes/Threats?, Why us?,  Why now?, Market size?,  Risks? & Critical Marquee Themes ?
  1. Customer Validation (Ideas or themes)/ Internal customer facing teams validation
  1. Brainstorming (three key stakeholders - Product Management -> market needs/problems , Product Designer -> Understand the persona & required user interaction , Architect-> Determines the feasibility)
  2. Iterate through steps 4-5-6 UNTIL you define a right "minimal" product which has a blend of form (UI) & requirements and that provides maximum value to the customers while reducing the complexity and meeting the your business and time to market needs.



Scoping analysis does help prioritize the requirements.  But, this could be done via a gut level feasibility analysis and not the formal scoping effort.   There are a few big issues with the scoping analysis method where engineering teams are asked to go into vacuum and come back with estimates.
 1 - You waste time and valuable engineering cycles
2 - You are asking for validation of the features from the engineering team which is not what engineers are supposed to do.  PMs have to put the right set of requirements from a customers / market and industry perspective.
3 - Create unnecessary stress between development and the PM team. No one likes the dance we do ...why do it if you can avoid it in the first place.

The steps outlined above are meant to gather the right data for you to help define the product. Some product managers like to go one level deep with this analysis and actually come up with some mathematical model to use.  There is no harm in doing this as long as you stick to the fundamentals outlined above. So, how do you go about adding  more granularity to this process. Well, add one more step

  1. Assign weights based on key factors (weight/factor).  Use a very simple formula  that works for you and you can justify.  But, this is after you go through the 6 step funnel process to identify the right product that customers want to use. 

Product Managers - Need to lead with radical ideas


Product Managers - Need to lead with radical ideas



Innovation is one of the most commonly used term. The word, which derives from the Latin noun innovatus, meaning renewal or change is a part of our day to day corporate vocabulary .  A WSJ article indicates how often this word is used:

  • Some form of the word "innovation" occurred 33,528 times in 2011, which was a 64% increase from five years before that
  • More than 250 books with "innovation" in the title have been published in the CYQ1'2012 . Just three months…

However, a few companies actually pursue or deliver "radical innovation" .  Product managers hardly get a chance to work on innovative ideas in large enterprises since these vendors  don’t provide an environment for individuals to work on game changing ideas. Instead, small incremental improvements are labeled as "innovative" deliverables  .  I always try to get back to the basics and then see how we can leverage these fundamental concepts in our day to day business world.  So, lets start with the basics first….

Innovation - What does it mean ?

Lets look at three definitions from three leading researchers in this field and identify the commonalities :

Theory 1 :  Leading the Revolution by Gary Hamel

Gary Hamel in his book defines innovation as a "Radical Product – Has the power to change customer expectations and redefine the basis for completive advantage". Companies do focus on incremental product innovations which are focused on existing products/services/ markets but in an increasingly nonlinear world, only nonlinear ideas are likely to create new wealth.  An article for INC by Gary Hamel further describes this in detail:

  • A radical idea has the power to change customer expectations : Not long ago, the PC was the ugliest thing in your home. Then Apple hired Jonathan Ive, a young British designer who turned that monstrosity into the first iMac -- a jazzy, fresh work of art that changed customer expectations. That's radical innovation at the product level.

  • A radical idea changes the basis for competition: In a world of increasing income bifurcation, conventional wisdom in retailing said that shoppers would go either to a Wal-Mart and that it would get ever tougher for companies in the middle to make money. Then Kohl's proved that conventional wisdom wrong. The company has half the number of stores as Sears and one-third the number of stores as J.C. Penney, and yet its market value is greater than that of either of its two century-old competitors.

  • A radical idea is one that has the power to change industry economics: By adopting a point-to-point routing system, Southwest Airlines keeps its jets in the air for two or three hours longer than most of the other airlines (which use the hub-and-spoke model), thereby using its capital more efficiently.

Executives and including product managers goals should not be to forecast "what might happen in the future but imagine what you can make happen".  A few other examples cited in his book shed additional light on "how" companies continue to drive innovation.

UPS : Getting outside the truck
  • Experimentation and rapid Learning approach to new business development
  • Bringing in new talents to fuel innovation.
Charles Schwab: Bricks and Clicks
  • Open and rapid experimentation allowing prototyping and testing of new ideas

Theory 2 - Fooled by Randomness & Black Swan by Nassim Nicholas Taleb

In his two books , Taleb regards almost all major scientific discoveries, historical events, and artistic accomplishments as "black swans"—undirected and unpredicted.  What we call here a Black Swan is an event with the following three attributes.

  • Its an outlier, as it lies outside the realm of regular expectations
  • It carries an extreme impact
  • In spite of its outlier status, human nature makes us concoct explanations for its occurrence after the fact, making it explainable and predictable

Google, Microsoft office are examples of black swan products that have fundamentally changed the way we search and forecasts our business.

Theory 3 - Blue Ocean Strategy by W. Chan Kim & Renee Mauborgne

Authors describe the concept of value innovation.  Value innovation is created in the region where a company’s actions favorably affect both its cost structure and its value proposition to buyers.  Cost savings are made by eliminating and reducing the factors an industry competes on.  Buyer value is lifted by raising and creating elements the industry has never offered.  Over time, costs are reduced further as scale economies kick in due to the high sales volumes that superior value generates. This leads to what the authors introduced as a vital concepts. Red Ocean vs Blue Ocean.

  • In the red ocean, differentiation costs because firms compete with the same best-practice principle.  Here, the strategic choices for firms are to pursue either differentiation or low cost. 
  • In the reconstructionist world, however, the strategic aim is to create new best-practice rules by breaking the existing value-cost trade-off and thereby creating blue ocean.

Red Ocean Strategy
Blue Ocean Strategy
Compete in existing market space
Create uncontested market space
Beat the competition
Make the competition irrelevant
Exploit existing demand
Create and capture new demand
Make the value-cost trade-off
Break the value-cost trade-off
Align the whole system of a firm’s activities with its strategic choice of differentiation or low cost
Align the whole system of a firm’s activities in pursuit of differentiation and low cost


Where do innovative ideas come from ?

This is an interesting question and something that we all wonder about.  What's the genesis of innovative ideas.  I'd recommend reading  " Where Good Ideas Come From: The Natural History of Innovation by Steven Johnson". His book provides insights into what leads to innovative ideas.  Economist article provides an excellent summary of his key concepts :

"The first of the patterns is “the adjacent possible”: the innovations that build logically on previous breakthroughs. In technology, this results in the common phenomenon of several people inventing the same thing at the same time, because it seemed the obvious next step. Similarly, life itself emerged as a cascade of increasing complexity, and the forking paths of evolution allow one innovation to lead to another, such as the semi-lunate carpal bone that made velociraptors more dexterous predators, but subsequently led to the evolution of winged, flying birds. Cultural and social life is also an exploration of the adjacent possible, as one unexpected door opens and then leads to others."
" In a similar vein Mr Johnson explores the “liquid networks” that foster innovation, whether online, in coffeehouses or in ecosystems, and the “slow hunch” whereby an idea develops slowly and often wrongly, before suddenly becoming the right answer to something. He also examines the benefits of serendipity and error, which can each lead to beneficial insights; the notion of “exaptation”, in which an innovation in one field unexpectedly upends another (Gutenberg’s press combined ink, paper, movable type and, crucially, the machinery of the wine-press); and “platforms”, from operating systems to coral reefs, which provide fertile environments for new developments."
How do you foster innovation ?

Lets review how Google's fuels its innovative engine.  Interview with Eric Schmidt in 2012 provides good insight into how companies create the right ecosystem which includes a mix of smart individuals, culture  that promotes experiments and rewards success/failure to build an ecosystem of ideas.

"Early on, “we put in a system of mechanisms,” for innovating, Schmidt said, citing the  so-called “70/20/10 system.” This was a principle that everyone should spend 70% of their time on their core job, 20% as part of another team, and 10% on something blue sky. It was often honored in name more than the event, I’ve heard from insiders – if you’ve got a critical job and a tight deadline, you don’t give it up at that 70% mark. It was however, a good way for people to see projects all around Google, and test them against their own ideas". At Google, “We don’t have a two year plan. We have a next week and a next quarter plan. Most of our successful products were built by small teams reacting quickly.”

Why do companies fail to innovate ?

When we look for innovation, we expect it to come from startups . Large companies struggle to drive innovative projects/foster innovative ideas or create an environment that helps with experimentation.   Well, there are reasons why. One of the leading HBR article summarizes the key challenges.

"The classic traps" by Rosabeth Moss Kanter summarizes the key reasons why company's fail to innovate

Strategy Mistakes
  • Rejecting opportunities that at first glance appear too small
  • Assuming that only new product counts - not new services and improved processes
  • Launching too many minor product extensions that confuse the customer and increase internal complexity
Process Mistakes
  • Strangling innovation with the same tight , budgeting, planning and reviews as existing business
  • Rewarding managers to what they are committed to do and discouraging them from making changes as circumstances warrant
Structure mistakes
  • Isolating fledging and established enterprises in separate silos
  • Creating two classes of citizens - those who have the fun (innovators) and those who make the money (mainstream businesses)

Learning's for Product Managers- Think like a startup

With the background in place lets look at how does this impact the product managers.  As a PM, its your key "responsibility to bring the future into the present".  As a PM it is your responsibility to create the blue oceans or the black swans or define radical ideas that have the power to change the competitive  & industry dynamics and above all fundamentally change your customer expectations.

So, where do these ideas come from.  There is no one source of ideas. But, I truly believe that the right environment with individuals who are motivated and are a part of a culture that promotes experimentation and rewards success and failures can lead to innovative ideas. This kind of an environment is usually there in a startup.   Startups have no legacies, they are in search of blue oceans, do not have existing customers to guide them or lead them to solutions or existing processes that limit their thoughts. They are outside the box and thus can lead to breakthrough innovations.  Irrespective of the environments PMs may find themselves in they need to think "outside the box" and focus on open and rapid experimentation allowing prototyping and testing of new ideas with their product teams.  Develop these fluid informal networks that helps you develop pipeline of ideas .  Many product managers rely on customers for these ideas. They talk to customers, validate the concepts and ideas etc.  Talking to customers is an important step in this process but as PMs you have to identify the "difference between the customers perceived wants and the real problem". Usually, Product Managers focus on the customers perceived wants only and thus ignoring the larger picture.  You need to strike the right balance between the top down driven innovation (lead by folks who feel the force) and bottoms up approach (customer driven )validation.  Blended approach  to innovation would be the right model as highlighted in this NY times article by John Kao  at the World Economic Forum in Davos , 2012. 



Product Managers should focus on developing the ecosystem of these promising ideas. A few are near term , a few are medium term and a few are long term plans which are in their initial stages.  Develop this pyramid, present it to management, ask for building an innovation team within your team, or build an innovation team by balancing your own product budget and connect the dots with all the innovators within your team and outside your team. It's the network of all these connections lead by you that will help build the ecosystem. Scoot Cook founder and CEO of Intuit in his speech at the world innovation forum in NY highlighted the need for experimentation  -  "Don’t be afraid to constantly be experimenting, and don’t be afraid to fail at most of those experiments".  To achieve game-changing innovation, Cook says, be willing to constantly run small-scale experiments, to develop a “culture of fast cycle experiments.”

Simple User Experience : Simplicity is the ultimate sophistication


In my previous blog on product requirements documents I had highlighted the need for  developing prototypes along with other artifacts like use cases/user stories etc for driving product management activities.  I highlighted the reason why ...since requirements and user experience are intertwined . They need to be looked at from one eye to define a usable product that provides value to the end users.  Lets review this topic in detail by looking at a famous quote that is often used in our industry today. I included a non IT definition to illustrate the important of simple user experience.

  • "Simplicity is the ultimate sophistication" - Steve Jobs
  • The ability to simplify means to eliminate the unnecessary so that the necessary may speak - Hans Hofmann (abstract impressionist painter)

Here are the core principles for delivering a great user experience that product managers must follow and stick to it at any cost. 

  • Focus on the end user and only the end user. End users interaction with the software is what should guide your requirements/design / development. Focus on a few features that would make your product usable.  Make it simple for end users to use .
  • Say NO to everything that compromises the user experience. This most importantly applies to your requirements , to the features you prioritize to the downstream development code that gets into the product. This implies that you would say NO to a lot of good ideas, a lot of customer requests, feedback from the internal teams, analysts etc. But, stick to this principle...this would help you eliminate complexity in the product and adapt the 80/20 rule. 20% key features that provide 80% value.
  • Provide a direct path to get the task done….a straight path is what you need.
  • Don’t pile features . More features would make the product complex and unusable. Focus on a few features that are usable.  Mathew May , author of In Pursuit of Excellence ,says the best ideas have something missing and what's missing leads to a more elegant solution .  Hint : iphone, ipad ?
  • Don’t just focus on how things look. Get to the next level and focus on how things actually work. A good UI does not necessarily translates into a simple user experience for the user .
  • Ship with minimal documentation.  A product that is usable does not require pages and pages of manuals.  You hit the mark if you pass this test.

How can you start to implement these principles ?

I'm not straightforward to implement these principles especially with existing products with legacy customer base . But you got to start somewhere and the further you delay these decisions the more complex your product becomes. Here is a quick recommendation to help you get some discipline around it :

  • Review the value proposition of your product?
  • Identify why your customers buy the product?
  • Understand how they use they use the product ?
  • Create your customers profile (buyer, user)?  List all the tasks they do?
  • Keep this profile on your desk or as the background image on your laptop/desktop?
  • Keep the core principles in sight ? Always
  • Review every features, request, additions to the product from this lens

Product Strategy: What does it mean? Need to understand these concepts to develop the strategy




Product Strategy: What does it mean? Need to understand these concepts to develop the strategy   

Strategy, business model, strategy planning...buzz words are commonly used terms by the product managers. However, a few selected product managers that too with a strategic planning experience actually understand the entire strategic planning/development process in detail. Sharing the basic concepts along with the process product managers need to follow to develop product strategy. 

What is Strategy?
We don’t need to reinvent the wheel on this. Let’s look at two definitions:

  • Harvard professor Michael Porter defines strategy as "a broad formula for how a business is going to compete."   It's the creation of a unique and valuable position, involving a different set of activities.
  • Bruce Henderson, founder of The Boston Consulting Group, defined it as, "a deliberate search for a plan of action that will develop a business's competitive advantage and compound it"..."competitive advantage is founded in differences."


Strategy is focused on what is needed to create sustainable competitive advantage & deliver customer value.

There is a wide spectrum of paradigms that have emerged over the years to help companies develop strategies. Here is a snippet of how the strategic world looks like from strategy-business.com in their issue 61 (Winter 2010).



What is a business model?

Business model describes how the organization will implement the "Strategy". Business model is focused on the how the organization will create and deliver substantive value to customers.   Product Managers often confuse strategy with the business model.

What is a Strategic Planning?

Strategic planning is the process of conducting research, defining strategies, identifying and developing the business models to achieve the core vision company has outlined.  Simply, put this is the systematic process company follows to answer three basic questions:



  • What's the current situation?
    • External - Market, Industry, Competitive, Environment …
    • Internal - Financial, Current SWOT
  • Where do we want to go?
    • Select the key strategic focus areas
    • Identify strategic options/ alternatives
    • Identify the strategy
  • How can we go there?
    • Execution plan

Product Strategy
So what does it mean for product managers?  This diagram illustrates how the PMs should go about developing the strategy which then leads to product roadmaps.





What’s wrong with the Product Requirement Documents (PRDs)?


PRD is the most commonly used mechanism for product managers to describe product requirements for a release. PRDs forms the basis of requirements for both Waterfall and now even with Agile software development processes. However, there are some fundamental challenges with the PRD model and I’m sure if you take a step back and analyze the pros and cons of the PRDs...you will find commonality between your thoughts and what I have shared below.  Not sure who invented PRDs but I’m sure this person/organization didn’t have just the word document as the fundamental way to define products.  So, lets start with the challenges first :

Take Time to Write
Product Managers spend considerable amount time on the document.  During this time your product teams are in waiting mode and management is anxious to figure out what’s next. So, cycles are wasted and engineering management cannot plan for what’s next from a staffing, budget , platform perspectives until this document is firmed up.

User Experience is an after thought
This is the biggest challenge with the PRD. They are a bulleted list of requirements ...very verbose but cannot describe the user experience. User experience is the most important element of a requirement...experience does not only imply the UI. It's every touch point the user has with the product. 

Static in nature
PRDs are static documents. However, development is a dynamic process...in fact, agile development is used today to help give structure to this dynamic nature of software development. On the other hand , the most crucial document that is used for software development is static.
 
Error prone scoping Analysis
Engineer cannot actually provide the scope of the work until he really understands the requirements, gets a chance of putting a high level prototype or design document . However, we hardly give this "must needed"  time and force the engineering team to come up with the estimates to help identify the next spot on the roadmap . Thus, what you get usually are high level estimates with a significant error margin in them and off course very conservative.  PMs are still not done.  Then, the next round of discussions start around the negotiations. Give and Take...

What you ask for is not what you get ?
We all have lived through this. What is specified in the word form in the document is different then what you get? Why is this? Because requirements are subject to interpretations ...PRDs cannot capture the entire context of the requirement.

Cycles after cycles are wasted
The ping pong game between engineering and product management on requirements is a waste of time and crucial product release cycles are wasted. It causes frustration, results in lack of trust, results in throw away work. PRDs usually start with the complete wish list from a PM and ends up with what should have been there from day one prioritized as the right feature set for the release. This is a significant waste.

Cross functional teams have no clue what’s in the release
Even though PRDs exist but honestly the only teams that read it are usually the engineering staff. As a result, cross functional teams are in dark and they all wait for the final PRD and some kind of a dev milestone to understand what is in this release. So, they are in dark and cannot plan for future deliverables.

Too long to read and it changes...
Hardly a few engineers read the entire PRD which takes time and by the time you read it usually changes . Infact, the change is constant since you are going and forth from a market perspective but also adjusting based on all the discussions.

Management is left in dark
Executive team usually gets a few bullets on a power point to help illustrate what the next release would look like. These bullets form the basis of budget approvals, decisions and pretty much the “Go/No Go” decisions for the project.

Do not describe the requirements but end up describing the solutions
In order to be precise and to make sure what you ask for is what you get product managers end up identifying the solutions to the team instead of the requirements. PRDs suffer from this common problem.

Cannot be validated

There is no way to validate the PRD and the assumptions associated with the requirements. It’s not something you can put in front of the customer ans ask for feedback or lead them to discover new requirements.

This list can go on and on...but I’m sure you will find a connection between your process and these data points . On the positive front...PRDs in its true form are a useful document when you know the exact set of requirements and can clearly / very clearly articulate it and expect little to NO changes to it as you move through the release. Usually, this is true with waterfall development models or shorter releases.  This is hardly the case in the software world we live in these days. 

So, what’s the solution...

Solution lies with the startups and entrepreneurs who have built companies from scratch. This will be a topic for my next blog...but here is the hint. What do startups do differently? What do Entrepreneurs focus on initially when they have limited availability of everything ...money, cycles, resources etc?