Answering the question of how to plan a good product strategy is one of the most important questions any budding inventor or entrepreneur should ask themselves before commencing in any “product focused” business endeavours. Failure to do so, will almost certainly end in a failure and you will not meet your customers expectations.

Defining the Product

But, before I begin to drill down and discuss the details of how to design a good product strategy, first I must address something that comes even before we discuss how to plan a good product. Believe it or not, the following simple questions are more often than not completely overlooked.

1. What problem does the proposed product solve?
2. How much time and money will the “Product Solution” take to develop?
3. Can the product be sold in order to make a profit?
4. Is there even a market for the bloody thing?

As simple as these questions may be, software inventors and creators have a really hard time dealing with and facing up to the answers of these four simple questions. Why, because it may mean that their idea, vision or dream is placed into jeopardy. Because of this, stakeholders in the food chain often purposely overlook any issues raised by potential customers or salespeople that may challenge the advancement of their original product proposal or even lead to the simplification of the development requirements.

You read correctly, sometimes there are simple solutions to aching problems and they don’t require a massive amount of time and money to develop. Rather than that being a good thing, some software development teams and sales people see simple solutions as a threat to their livelihood. This is probably due to the fact that they don’t always have all of the answers to all the questions that they profess to have. As well as the fact that prolonging the time and cost of development is also a factor that software engineers, sales teams and implementation engineers factor into their time and money estimations. In addition to this investors often also try to pump up the costs because a higher investment could potentially produce a higher profit margin.

I remember performing a demo of a brand spanking new, fully integrated multi product “next gen” solution, for one of the largest software companies in the world. A packed auditorium of solution architects and deployment engineers eagerly and quietly listened.

When it came time for questions and answers, a polite well dressed lady in the back of the hall quietly stood up and asked me if they would still have job tomorrow, to which everyone in the room burst out laughing.

The point being, that nobody was interested in anything that I had enthusiastically said. Rather, they were all just sitting there thinking and calculating their own personal angle to the change in their reality. My answer was a simple one, instead of them only being able to perform a single system deployment per month, they would be able to perform one every day and also from remote locations (home).

In addition to the technical aspect of defining a products design and its overall strategy, there are a few additional factors that you should also consider. Impatient investors together with their willing participant tech junkies try to justify their original product idea and trajectory. This is because they are convinced that they on the cusp of the next best thing, since the invention of the wheel and sliced bread, and of course they know better than everyone else….

After all, they are software developers, thus they are smarter than all the plebeian fools that are trying to douse their dreams with reality and negativity.

The Flip Side

Of course there are many exceptions to the perviously mentioned scenario. There are numerous products that succeed in breaking ground and creating brand new realities. They are too numerous to mention here. More often than not if the truth be told, certain product successes are based on luck no less than on genius and cutting edge next gen ingenuity and innovation.

In recent years many well funded and very established software companies have begun to falter. They begin by reducing team sizes, then challenging the middle management about decisions that have been made, then they start scaling down their operations, down sizing and selling equity in order to try and balance the books. All this is done in an effort to by time until the next gen cutting edge product they are currently working on will miraculously return them to their former glory on the world stage.

Well, if the truth be known, the software industry specifically and technology as a whole has also grown, morphed and manifested itself into another beast altogether. Small lean companies with little or no overhead have begun to slowly chip away at the old school juggernauts. Once scoffed at as a non-issue by the big wigs and arrogant boards of directors of the day as a passing fancy. These small companies have become a force to be reckoned with, with quick time to market and no old code bases to maintain are beginning to take center stage. The big boys are falling by the way side one after the other, shouting blame and accusations at each other as their ships go down.

Keeping Your Eye on the Ball

Before commencing a discussion about a problem you wish to solve with you potential partners in crime it is imperative that you first consider that fact that you will most probably not hit the bulls eye the first time around.

The definition of success is the ability to adapt and change after a long list of spectacular failures.

On average, the ratio of successful software products to those that failed is about 1/10. That doesn’t mean that most of the software development time invested into the creation of a product is waisted. What it does mean, is that almost all of the final product deliveries are completely different from their initial starting point. This also means that the product definition may also change throughout the course of its growth and development. So, embrace the fact that everything will change and move in different directions.

Planning the Product

The product strategy describes the vision of the product and what it is designed to achieve. It is meant to provide the reader with an argument for building the application. It is in addition to a brief glimpse of a general functional specification. and marketecture diagram.

The product strategy document should be clear and motivational. It should provide answers to questions such as, how the product or service will improve an existing experience. It’s not about the specific features or functionality that may or may not be built, it highlights the benefits of this product. What problems will be solved with this product? Why will users love this product? How will the world be better once this vision is a reality?

Understanding the Target Customer

A product strategy is devised by first understanding “who” is the target customer, what is the market, and the underlying technologies that must be leveraged. You should actively involve designers and engineers in this discussion, as well as key stakeholders. The product strategy is something that should be discussed and reviewed actively.

The product manager should be very familiar and deeply involved in the product strategy. Many product managers make the mistake of believing that the product strategy must come down from above, and defining and building features without a well thought out product strategy is very likely a waste of time and money.

It is important to understand that the product strategy does not limit you to any particular set of features. You should adjust the roadmap constantly based on what you learn from customers and the market.

How to Define a User Story

Once the product strategy is defined together with a functional specification, they must be converted into user stories. A good ticketing system provides a simple and straightforward method for creating the user stories that include a set of simple steps and a pixel accurate graphic design when applicable. The user stories are created and placed in the Product Backlog of the ticketing system. The product backlog is composed of features that contain user stories and then bugs and defects.

The User story describes the functionality of the application and is designed to provide an understanding from a user’s perspective. Multiple user stories can be associated with a feature.

Manageing the Product Backlog

The product backlog contains a list of all the features, user stories, bugs defined for your product. Whether items were added to the product, release, or sprint, they are all included in the product backlog. The product backlog also lists defects and bugs that were defined by the Q.A team or any team member that has found a problem with the application version being tested.

Tracking the Progress of a User Story

In order to effectively track a user story there are several indicators that must be followed and there completion must be reflected in a predefined check list. The most important indicators are:

1.    Verify that the acceptance tests exist – The acceptance test is a description of the expected behaviour of a software product, expressed as an example or a usage scenario (user story).

2.    Complete the acceptance tests – the feature/user story is checked by the relevant team members. (the user story author, the developer, the QA engineer)

3.    Task Completion – Once the task has been completed and checked the task status is updated to “Complete” in the ticketing system.

4.    Resolve Defects – all bugs and feature/user story defects are resolved.

5.    Code Review – The developer performs a code review with another colleague to verify that there are no faults or problems with the new piece of code.

6.    Automation Coverage – The QA automation engineer includes the new feature into the automation tests.

7.    In Testing – Moving the user story from In Progress to In Testing

8.    DONE – Moving the user story from In Testing to Done

Receiving and Implementing Feedback

Customer feedback is one of the principles of the agile methodology. Speedily integrating and implementing customer feedback in the sprint cycles is one of the major reasons for the initial creation of the agile development process.

Once the user story is moved to the “In Testing” stage, the QA engineer then performs the test and code review together with the relevant developer according to the predefined acceptance tests. The acceptance tests represent the story definition of “Done”. 

Closing a User Story

During the development process the software engineer tracks the progress of their assigned features and user stories. Once the code has been written and committed to the application branch and all unit tests have passed, the developer then changes the state of the user story to Ready for QA. After all tasks are completed and the user story passed all of the predefined acceptance tests, it is then changed to Done. Any team member can change the state of a user story.

Software Company and Customer Communication

The most important aspect of building a successful software solution is interpersonal communication between interested parties in the production food chain. Failure to communicate in a simple and concise manner is root cause of almost all software product construction failures and problems. There is often a reoccurring bi-directional problem of misunderstanding between the R&D team the product team and a complete gap in understanding between the software company and the customers expectations with rare exception.

Attempts are made to bridge the information gap by means of presentations, technical documents and demos. What isn’t taken into account is the stakeholders ability to speak in the listeners language. The objective of an explanation is for the listeners to understand, so save the intellectual acrobatics for patting each other on the back in the coffee room and dumb down the technical explanations, nobody cares….

R&D Teams Method of Communication

The R&D team (developers/architects and technical experts) attempt to explain their understanding of the problem and it’s solution by means of a technical explanations. The more they feel that they are not being understood they delve deeper into the mathematical parameters of their understanding.

Product Team

If the product team is lucky to have team members with a technical understanding of the product, then information transfer is almost painless. If the product team has an absence of sufficient technical expertise, they attempt to decipher the technical explanation and convert it into sales jargon. They then relay their understandings to the customer. (this is a major stumbling block and can potentially cause major problems).

The Customer

The customer receives the product material from the software company and then attempt to translate it into their understanding of what they think the explanation really means.

This in itself is one of the most important, if not the the most important traps that you can fall into.

Why? because the customers understanding of the technical aspect of a software solution is limited to a comparative assessment which is based on only products that actually already exist.

Whether customers like to admit it or not, they are usually incapable of being able to accurately imagine things that don’t already exist. They understand things by means of comparative analysis (even an early adapter is not an product inventor or creator). To further emphasise this point, a skilled and experienced practitioner often employs the use of analogies which helps create a common ground of mutual understanding and then slowly builds the product understanding and definitions from there.

I don’t think that I have ever worked on a project where the customer completely understood everything that the R&D and Product teams had painstakingly explained to them. This simple yet complex problem can potentially create friction between the customer and the software company and be the cause of a very painful and frustrating relationship.

Finally, Don’t Forget to….

Remember, that once you have finished all of your insanely amazing product plan and stagey, don’t forget to share it with all of the stakeholders involved, including your customer…. Nothing can be kept a secret for even, in the end all stakeholders learn, extrapolate and understand everything. So, keep them up to date and involved as much as possible.

Most importantly, keep the customer in the loop …. and have fun 🙂