BA community

2022-08-30 15:00:09 Открыть/Комментировать

2022-08-25 14:03:09 ​​Scope creep and how to avoid it

Scope creep, also known as kitchen sink syndrome, is an issue of the uncontrolled changes or characteristics that had not been taken into account from the beginning of a project and are intended to be added to it.
Even if those changes are small, they can cause the project to take longer than planned and, therefore, be more expensive than originally stated.

Why it happens?

Lack of understanding: It can occur on the client or vendor’s side, when the stipulated agreements are not fully understood before the project begins.

No plan: By presenting your client with an outline of how the work will be carried out, you can avoid last-minute changes and save time by identifying what has been missed earlier.

Gold plating: This happens when the team adds features that the client did not request or that were not previously discussed.

How to avoid it?

Document everything.
There is nothing better than having everything written:
Documenting can protect both parties that the agreed requirements are met without missing something.
Provide transparent outlined plan and define project scope clear to you and the other stakeholders in the project.

Don't hesitate to ask.
In fact, this must be on both sides, since it is vital that you clearly know what the client's requirements are and that both agree on how it will be carried out.
Сommunication must be constant, clear and allow collaborative work. Therefore milestones will be planned wich will help to optimize the project as it progresses.

All changes have a price.
Make sure that the customer and the team takes this into account. Any, even a very small change, at first glance, may lead to extra costs and negatively affect project success.
To avoid constant and haphazard changes establish the change control process. Ask the requester to follow the process to suggest changes. And the most important don’t forget to review those requests with project participants to decide if it's worth changing the scope of the project Открыть/Комментировать

2022-08-23 14:00:07 Открыть/Комментировать

2022-08-19 14:00:11 ​​Let’s finish to discuss Discovery steps

Proposing a solution
When we already know what you are going to build, you can start thinking about HOW should it be implemented. Two types of modeling should be done:
1. Functional
a. Use cases
b. Process diagrams
2. Object
a. Internal objects
b. Border objects
i. User interfaces
ii. Integrations

But don’t be afraid, at this stage we are doing just high-level modeling without diving deep into details. Our goal is to create “just enough” prototypes that will help us to explain to your potential customers how the product is going to work so that we will be able to test it.

Testing solution
Now it is time to return to potential customers one more time! This time - with prototypes.
Testing solution (or Customer validation as it is called in Cust Dev methodology) includes testing your first prototypes with potential users.
In the discovery phase, we usually avoid writing even a line of code. Prototypes on this stage can even look like screens drawn on napkins, but usually, it is more serious prototypes created in InVision, Adobe XD or other similar tools.
And of course, it is an iterative process.

At this stage, it is very important to stop on time. When the concept is good enough the time comes to move further. You will always be able to further improve it when the product is already on market.

Vision detailing and preliminary plan creation
My congratulations! Finally, you know WHAT you are going to create and HOW it is going to work.
So now the time has come to detail your vision and create a plan.
A good plan consists of
Vision and scope
Design concept
Technology stack
Architecture vision
Story map
Roadmap
Time and Budget estimates
Risk mitigation plan

Of course it should not be a detailed plan. It is just required to align the product team, detail MVP scope, and plan time-to-market. There is a lot of work to be done at the following stages, but at least, as the result of the discovery phase, you:
Can be sure that the product is worth doing
Have a clear vision of how is it going to look like
Have an understanding of how much time and money the product development is going to take.

Conclusion
As you can see, the discovery phase is one of the most important stages of any product lifecycle. Its main purposes are mitigating risks, shortening the time to market period, and saving a lot of time, nerve cells, and money. Открыть/Комментировать

2022-08-16 16:48:52 Открыть/Комментировать

2022-08-12 16:00:08 ​​Let’s continue topic Discovery

Product Discovery Phase Challenges

So the Discovery phase is very useful, but it is also one of the toughest periods of any product's life.
First of all, you should understand your clients and their needs. When starting a new product you should always remember the first rule of a product owner: You are not your customer!
That means that everything should be tested. It is just like in science - everything you think your client wants is not a fact, it is just a hypothesis to test.
The second problem is creating the right ideas, and not missing anything important.
Identifying customers' problems is not easy itself, but it is just the beginning of the journey as at least 80% of success lies in the details of implementation.
And the third difficulty lies in discarding a lot of ideas that you like.The good thing is that you will be able to return to some of them later when your product will already be successful in the market. But at first, the product team must concentrate on just MVP scope to provide Customers with a “just enough” solution that will help them to deal with a problem that is important to them. And the Discovery phase is precisely the right time when you should understand the scope of your future MVP.

Product Discovery Steps

Understand your Customers, Market, and their key problems
You should start with a deep understanding of potential product Users and their problems which can be solved by using the product.
It is a strong starting point and even at this stage sometimes the whole product vision can be changed.
The key deliverable of the stage is User personas which are developed and included in the Vision and Scope document.

Testing problems
Here we return to the main idea of hypothesis testing for the first time.
Cust dev methodology is far beyond this article's scope, but the main idea behind this is that your vision of potential customers' problems and their importance for customers is just a hypothesis that should be checked.
At the Customer discovery stage (as it is called in Cust Dev) you don’t propose solutions, but just ask your potential customers if they really do have problems you think they have and are they ready to pay for solving them.
The key deliverable at this phase is a product backlog which consists of user stories that are really important to your potential customers.
But sometimes this step can change the whole concept or even cause the discarding of the product idea.
At this stage, your potential customers help you in answering the following question: “What exactly are we going to create and Why?”

In the next episode we continue discussing other discovery steps Открыть/Комментировать

2022-08-10 16:00:09 ​​The winner is the topic about discovery
Let’s start.

So what is the Product discovery phase? In simple words, the Discovery phase is a part of the planning phase from PMBOK. It is strictly required to create a product roadmap and to make budget cost estimations.
The Discovery phase usually results in
Vision & Scope
Design Concept
Architecture Vision
Sometimes discovery phase can even result in avoiding spending millions on a product that is not worth it.
So let’s get a deeper understanding of what is a Discovery phase and what it consists of.


Product Discovery Phase Benefits

So let’s return to our skyscraper example. Just imagine you are building a skyscraper and when the 50-th floor is ready, you suddenly understand that you have forgotten about one additional entrance just because your plan has not been detailed enough?
Well, OK, in this case, you really can do nothing, and in software development, you actually can add one additional entry. But there is no such thing as a wonderland, it is going to cost the product team way more time and money than it might cost in case this entrance had been included in the preliminary plan.
The other problem is time to market, which is deadly important to any startup product.
Of course, the Agile approach to software development is the best way of managing product development, but in some cases, it can be quite dangerous. A lot of products fail because it is very easy to dive deep into details or fall into scope creep when all features seem to be so important. Agile is good, but don’t forget about clear and precise vision! Without that, time, effort and money are going to be lost.

So one of the main goals of any Discovery phase is to create such a vision and align the whole team with it. Открыть/Комментировать

2022-08-08 11:00:06 Открыть/Комментировать

2022-08-05 13:00:43 Открыть/Комментировать

2022-08-05 10:00:20 ​​Finally!
The last part of article "BA’s work in the Presale phase"

Input data
Depending on the inputs provided by the customer, we can choose the approach to the work of the BA in Presale phase. Let’s discuss the main possible cases:

A working solution with full design documentation and well-defined improvements
The best option for BA. We’ll need only to review an existing documentation and estimate new features. A list of functions with a description is also being prepared. BA answers the questions from the team during estimation. In this particular case an additional communication with the customer may not be required. Output: feature list with estimation.

Working solution without documentation
The BA performs reverse engineering activities with the solution, estimates new functions, prepares a list of functions with a description. We answers to the team's questions during the estimation on our own or request communication with the customer.
Output: follow-up from a meeting / call from the customer, feature list with estimation.

Mock-ups/prototypes without documentation
The BA investigates the presented prototypes, identifies the main functions, prepares their list of features with a description. We answers to the team's questions during the estimation on our own or request communication with the customer.
Output: follow-up from a meeting / call from the customer (if any), feature list with estimation

Documentation
The BA examines the presented documentation, forms a list of questions, creates a draft of feature list, parses the draft of feature list with the team, collects questions. We clarify all questions during the communication with the customer, composes a final feature list.
Output: feature list with estimation, a list of questions with customer answers.

Idea
The BA asks the questions to the customer according to the checklist and processes the received information. A high-level feature list is composed and estimated with the team. If necessary, the communication with the client is requested several times.
Output: checklist with the customer's answers, high-level feature list with estimation.

That’s all we’d like to tell about the role of BA in the Presale phase.
Please, fell free to contact us if something needs an additional discussion Открыть/Комментировать