Vision, strategy, roadmap – do I need it?

/in /by

The implementation of innovative services or products is not limited to happiness, hard work or knowledge of the field. While the above factors may prove to be extremely useful, you are far away from success without a defined vision, strategy, roadmap and backlog. In this article you will learn how to tidy up product development to create a solution that everyone will love!

Wide image

Should I run out to the future to be successful? No doubt yes!

Focusing only on the coming weeks (in the Scrum, for example on the nearest sprint) without a defined vision and strategy, can lead you to a dead end. While this approach can be justified under conditions of extreme uncertainty and a very dynamic environment, the success of any solution starts with the right strategic decision. Sometimes we can also find the opposite situation – we are visionaries of our product in the future, but we do not have a specific plan for the next week. Neither one approach is quite right and the correct balance between “big” and “small” image will bring you closer to stable growth.

Action plan

So how to approach product development from general to specific? You need both a high level plan and a sufficiently detailed plan. This will help you define sequences of vision, strategy, roadmap and product backlog.

Vision

The vision is really a description of your main reason for deciding to create a product. It should be “backed up” by your motivation, as well as the positive change that is to be made. Remember that you have to believe in the product you are creating! The vision answers the question – why do I make a product? It will also help you in defining lower level solutions.

Example: I want to create a solution that will help manage household finances and control home budget. This way, people will be able to effectively manage their budget and be more aware of their expenses.

According to Roman Pichler, the vision should be characterized by four factors: to be large, inspirational, concise and accessible. A big vision, such as “being aware of your expenses” increases the chances of purchasing a product by people with narrower perspective, such as “I want to save money for my next vacation.” Moreover, it is easier to change the strategy (if necessary) while maintaining the same vision. Briefness makes the vision easy to communicate and understand.

Inspirational vision provides motivation and gives the direction to development. The vision facilitates collaboration, unites people and ensures continuity in a changing environment.

Strategy

Strategy is a high level plan that helps you achieve your vision and goal. Defines how the vision will be realized. It would be helpful to find answers for the following questions: for who is the product, what need or problem it solves, why should someone use our solution, what is the product, what are the business goals, why should you invest in this solution or what sets us apart from competitors. There are several helpful techniques and tools that help define the strategy and its key elements: market and needs, core business functions and objectives.

Also keep in mind that strategy is not the final plan for your product. With the increase in awareness or maturity of the solution, your plan should also change. Therefore, review your strategy at least quarterly.

Roadmap

A roadmap is a description of the implementation of your strategy. It’s as if you’ve defined a strategy that has been translated into specific actions with the established dates, key functions, and goals.

Product Backlog

At the very end there is a product backlog that includes the details needed to complete the roadmaps: diagrams, mockups, detailed tasks (in Scrum user stories and epics). Make sure your backlog is characterized by the DEEP rule (detailed appropriately, emergent, estimated, and prioritized). I would also like to emphasize that changes made to a product backlog can affect a roadmap, strategy or even vision. Changes also work in the other direction – not just from general to detail.

Summary

To summarize all of what I wrote above, please look at the following

Vision Responses to the question – why do I create a product and includes the positive change that the solution will deliver.
Strategy Defines how the vision will be realized (mobile product, book, SaaS software).
The Roadmap Roadmap contains a concrete action plan with fixed dates, functions, and goals. It describes the implementation of the strategy.
Product Backlog Product Backlog contains all the details needed to complete the roadmap.

I hope this article helped you sort out the basics of product development planning. If you have any questions, please write in the comment. If you liked the article, then share it on Facebook!

5 myths about the role of Product Manager

/in /by

Myth 1. Product Manager = Project Manager

In many companies, I encounter situations in which Product Manager performs part or all of the responsibilities of a Project Manager. Although such a solution is possible, this is not a perfect approach and in most cases it will not work. One of the most important things is that these two roles should answer completely different questions:

  • Product Manager – What should the product contain? Why is it important?
  • Project Manager – How should this be done? When?

The role of Project Manager is focused on time management, cost management, team coordination. It is not a person whose purpose is to identify and analyze requirements. It is the Product Manager’s responsibility to identify the problem, choose the best solution, and make sure that the product meets the needs and needs of the user.

Myth 2. Product Manager with technical experience will always be a better employee

This aspect is important and relevant for IT products. Often, technical expertise is very helpful with avoiding misunderstandings, for example by using a same language with the engineers. But do not forget that the main responsibility of the Product Manager is to create a product that will be attractive to the users. Your task is to give the right direction and proper understanding of your users rather than the physical building of the product. You do not have to understand architecture, logic, know how to solve every technical problem. These are the skills that engineers have.

Of course there are situations where technical knowledge may be necessary. A good example is a typical technical product such as a system for monitoring the performance of other applications. If PM is not aware of technological constraints, it may end up endangering the end product.

Myth 3. Product Manager tells the team how to make a product

Nothing is more wrong. Product managers should not decide on technical solutions and how to solve the problem. The most important question you must answer is what should contain the product to meet your expectations. Not how to do it. I always come up with the premise that the solution (how?) should come out of the whole team. Nothing stands ont he way to prevent ideas and inspire the team to act!

Myth 4. Product Manager builds everything that the customer requests

It is very important to listen carefully to the needs of the users and to try to be aware of their real situation. Product managers should look further, to search deeper goals and answer for the question “does the customer really needs this”? Unfortunately, in many cases customers do not know what they really want and are not aware of technical solutions. To find the right requirements, use the tools that help.

Myth 5. Product Manager’s job is mainly to describe the requirements

Product Manager’s work differs from the duties performed by engineers or UX designers. Engineers provide technical solutions while UX designers create prototypes of potential solutions. For Product Manager, delivering requirements is not all. This person is responsible for building a product vision through the prism of success. Defining and describing user needs is only a communication technique that facilitates the creation of real value by the team. Often it does not necessarily signify a description of the requirements. In my work I put the conversation, face to face, in the first place. Descriptions as prototypes, user stories or use cases – I treat as a supplement to meetings. It is important to emphasize the uniqueness of communication, to ensure that the team understands the ideas conveyed and has implemented a solution that meets the requirements.

Summary

I chose 5 of the most moving myths during my work with products. What myths do you meet?

Do not worry about the format of your user stories

/in /by

User stories are probably the most common technique in Agile to list functions or product errors. Apparently easy to define, in fact can cause many misunderstandings if they are not properly identified and told. There are a lot tips and rules for creating stories. But is there an ideal method? You will find out below. I also encourage you to read this article if you use other techniques to define tasks for the team on the daily basis.

The format of your paper cartons

There are many tips for creating good user stories. One of them is the principle that stories should be in line with features described using INVEST acronyms (William Wake, author of Extreme Programming Language and Refactoring Workbook who used acronymes for the first time). Often used template is “As <user type> want <task name> to achieve <target>”. The above tips and many others come down to the fact that many Product Managers are focused solely on creating a story that is consistent with the rules, which often leads to many misunderstandings. Some even argue that the business value of a story should be the most important, others, for example, that „I want” to be at the beginning. So I go against all these people and emphasize: Do not always worry about the format of your stories!

There are several reasons why you should not worry about the structure of the storyline until you have included all the key elements listed below:

  • From the way you write down the story, it’s much more important to talk to the team whose “task card” should remind you of it. While the information in the story is true, every format is a good starting point for discussion.
  • There is no clear evidence that the choice of a particular story-making policy over another will improve the team’s performance significantly. Also keep in mind that all tips / policies may not necessarily be up to you.

Templates are just a standard that may look different in your project. While using the “As <user type” want <task name> to achieve <target> “is a good way to start discussion, do not stick to a particular template regardless of circumstances. Otherwise, you might end up with a story like “As a system, I want a report …”. Instead of unsuccessfully pondering on fit into a template, verify whether the people are actually stakeholders and whether they do want what was just defined.

Experiment

I encourage you to experiment with your user stories. The following steps can be used as a help:

  • Create stories at the beginning, but add all the details later (for example, during recurring meetings with the team which you will use to discuss future tasks).
  • Do not write obvious solutions and thoughts
  • Think of a larger number of stakeholders who may be interested in the function – consider whether it is not worthwhile to divide the story into smaller parts.
  • Use pictures instead of words
  • Ask questions

Using different formats can be a great way to spur a discussion with your team or look at a task from a different perspective. In many cases you will also avoid false stories. Alternatively, you can use an entirely different description of the requirements, such as use cases. This technique will help you more in the case of a precise description, for example, by adding preconditions and exceptions. Use Case’y will also work better if you do not have the ability to engage the team (example: for remote work) in the discussion or in the definition process.

A good way to move around the discussion is to write  down questions, not solutions. Focus on the problem, mimic the user instead of reflecting on the physical implementation.

Summary

Tips and templates are extremely helpful in defining tasks. Remember, however, not to follow blindly in one direction because it can give the opposite effect to the intended one. Experiment with different templates, think over the questions instead of solutions, and most importantly – talk. With these simple tips, your work will be much more efficient and will help you avoid many misunderstandings!

How to build a product that nobody wants?

/in /by

Is building of a product or a service which nobody wants difficult? Definitely not. Just follow a few tips listed down below and I can assure you, that everyone will really quickly forget about your product. Would you like to avoid this? Then take opposite steps!

Do not talk with the users about their problems.

Will your product succeed if it will not contain answers for the problems and needs of the users? Definitely not! Actually, you will only waste a lot of time, money and nerves to build something, that nobody wants!

I have put this point on the first place, because I really often see this kind of a problem appearing in the beginner Product Owners / Managers. We implement features, that seem to us necessary, but not to our users. Remember, that in 99% of cases users have no idea what they want! Therefore, the role of the product manager is so important.

One of my favorite examples is the theory of the “faster horse” made by famous Henry Ford. While the horses were the primary form of the transportation, Ford asked his potential customers about their expectations for the faster communication. The answer was one – “We want faster horses!” In fact, Ford’s customers needed more efficient and convenient form of the transport, which wouldn’t have to rest as much. So, if you will find out what are the real problems of the users – not those, that customers are able to express, then you will identify opportunities of creating products, that will delight your customers.

To resolve some issues, we are forced to pose hypotheses relating to the principle of the service or the product. Remember, however, that your assumptions have to be verified as soon as possible! Perhaps, you will find out, that the product requires some amendments to be sure, that your product will actually deliver what your customers are looking for. Lean Startup and building MVP will help you with this.

Do not define users of your product.

Are you able to answer this question: Who are the users of my product? Believe me, the answer in many cases may not be so obvious! If you do not know for whom you are building a product, whose problem you solve or who currently uses your product – you’re about to build something, that nobody wants.

Do it well. Define the main points in your product. Select the key points and under these terms try to develop your product. Very important: Do not try to please everyone at once. You have a very small chance for succeeding. Try to also define user segments based on the data, if possible.

Remember to release the product only with all the functions.

The first rule of building a product – we test and release only when everything is completely finished! After all, our users expect all the features to fully meet their needs. Shall we worry, that something might go wrong? No.. not a chance, our analysis of the market was just flawless! # BadProductAdvice

Do not go that way. Let me introduce you an example. One of Apple’s products – Apple Newton, was launched in 1993 after five years of the development. You probably do not remember, but Apple in their ads promised a portable personal computer (so-called ‘palmtop’), which would contain all the wonderful features along with the possibility of writing on the screen using fingertips. Then, when the product was finally released, it turned out to be too “heavy”. What’s worse, the most important functions did not work properly. Finally, in 1998, it was withdrawn from the market. Apple proved to be too ambitious in their plans and a product, that was doing too much at once, was a failure.

Do not be afraid to test your ideas, concepts and give users the product to be tested as soon as it is possible. Select only those features, that affect only your key indicators. Feedback may turn out to be priceless! You will know if you are going in the right direction, if the product will need to change its business model. Test whether the functions are used in accordance with the established hypothesis. Does it resolve customer issues? Bravo! Defined indicators have not changed? Find the cause, talk with the users. Perhaps the problem might be even unintuitive interface.

Do not worry about the user’s experience.

I would like to ask users of your product a few questions:

• Is the product simple and intuitive to use? Is navigation and any interactions not causing any problems?

• Is the application useful? Does it perform any valuable role? Does it meet all the needs?

• Can the use of the application be mastered in a short time? Can this be done without resorting to complex instructions?

• Is the visual aspect of the application attractive?

• Do you trust and believe in their content?

If the answer to any question is NO – the success of your product is much less likely.

Have you ever had a chance to buy a book from Amazon? Did you see how simple it is? One click can make the e-book appear in our reader. And all of that is happening in less than a few seconds!

So be sure to take care of the User Experience – in the end product is for your users, not for you!

Ignore the feedback

You release a product in the world, get feedback from everywhere, ignore it and continue the development of the pre-planned plan, because you assumed, that your customers have no idea what they want. So why their feedback should now be valuable? #BadProductAdvice

You’re doing it wrong. I have recently come across the official site of one of the biggest supermarkets in Poland on my Facebook page. Under each opinion or feedback from the user, I noticed the same message copied and paste sent as a response. Would such an approach attract more customers? Definitely not. You run fan page of your product? Should you receive negative feedback? Then use it as an idea of your next improvement!

Do not ignore the opinion of your users (especially negative), just simply control them. Create the appropriate support, give your customers the opportunity to comment. Ask users what they lack, a good option is to separate the place where users can add new ideas and vote on them. Well-used feedback is priceless.