Why do people make software? To solve some problem or unlock some opportunity.

But what if the problem isn't real? What if it's just a fantasy of a customer or your manager? What if it doesn't actually exist?

The key to understanding the problem is its impact on the target audience.

In this product-detective game, participants will take on the role of detectives, searching for a problem through indirect clues hidden in interview results, quantitative analytics, qualitative research, surveys and other artifacts of user research and requirements elicitation in the analyst's arsenal. 

Having found it, the participants will propose a solution by building a Value Proposition Canvas and defining an MVP for the product.

In this game, analysts will be able to go through the process of hypothesis verification via an MVP, from the moment of hypothesis ideation to the selection of requirements that need to be considered.

As a result of the workshop, analysts will learn to:

1. Accurately formulate hypotheses for the development of their products or projects.
2. Determine the scope and necessary composition of the MVP.
3. Articulate the vision of a successful MVP launch outcome.
4. Work only with stakeholders whose opinions are important for the MVP.
5. Identify critical scenarios that must be incorporated into the MVP to achieve success.
6. Understand how and with what requirements to work at the stage of creating and launching the MVP.

Many analysts, POs, and product managers often find themselves in a SCRUM that is far from the reference.

And some people start in it right away, without being able to find out what it really should be. But even if colleagues have relevant experience, they may find themselves in a team and a situation where the framework doesn't work, i.e:

• burdens the team's problems instead of solving them;
• interferes with goals instead of clarifying and approaching them;
• hangs weights of incomprehensible meetings and ceremonies instead of facilitating interaction processes within.

You can, of course, immediately say, "ew," SСRUM doesn't work for us. Or we can fix it and start using it properly so that it benefits the way it was intended.

One of the most important questions that an analyst should ask when starting work on an initiative (project, task, insert your variant) is for WHOM and WHY it is needed. Unfortunately, being swamped with the work of writing integration requirements and other technical details, analysts forget about this.

Within this workshop, we will give an opportunity to get back to the essence of the analyst's work, as well as take a little distance from the technical specifications and get up to the analysis level of the target audience and the value of the initiative. 

The workshop will be helpful for analysts, novice product managers, and anyone who wants to understand what important things need to happen before we start writing requirements. What we need to do so that our product does not turn out to be useless and unsuccessful so that all the efforts of the development team do not go in the bin because a critical stage in the life of a digital product has been missed.

Agile approaches were introduced to product and project development a long time ago.

But as soon as each company or manager has its own view on how it should work, the practical application can cause a lot of issues and lower the work efficiency. Often, framework success is perceived as "follow the rules to the letter, no matter what", which could undermine the whole project and team motivation.

We will talk about SCRUM because it's a well-known and widespread framework. We will talk not only about the analyst's suffering, but about how to make his involvement beneficial as well.

When the project is just started, its backlog seems clear and transparent. It looks like a useful tool for project goals fulfilment.

But over time, small mistakes, almost harmless on their own, turn your trusted management tool into a formless pile of tasks that can immobilize and halt any useful initiative you may have. And with each passing day, you spend more and more time and effort to manage it.

Your dev team is working hard. A lot of tasks are closed each sprint. But there is no progress. No value is delivered to the end-users. The backlog still looks like a bottomless pit.

Let's think together, what can cause such an unfortunate outcome and what could be done to avoid that...

Action-tale about Arkhipus, the sudden senior, and the magic matrix.

Once upon a time, a fresh middle analyst, Arkhipus, was assigned to a project with another, experienced analyst. But suddenly, at a welcome party with a customer, the experienced analyst crossed the red line with not so tolerant jokes, and the next morning, Arkhipus found himself as a first and only analyst on the project 

Together with Arkhipus, we will walk through all project stages, from discovery, scope and backlog management,  UAT, and till the final release, to unleash the power of the magic matrix!

Often, outsource development teams are separated from the business of a customer. 
People are jumping from one project to other, just closing tasks in a tracker, caring little about sense of what they are doing and value of their work.

In small and simple projects that are really not so important, but if that's a long project in the complex business domain, business context deep dive for developers can provide solution of solid increasing in quality and value for the customer. And sometimes even save the project from failure.

In my presentation, we will talk about issues that project can suffer without such business dive, how we can do this as analysts and what benefits the project can obtain from such dive and why the business analyst only can do this. 

Sometimes, there is only one analyst on the project. Sometimes a couple.

But what if we have ten of them, working for the same project?

Usual approaches for stakeholders and requirements management are not effective anymore. Best case scenario, they would be far less useful, but in reality, they can be even harmful to your project.

In my talk, we will review the work approach of such teams, processes that can reduce the chaos and establish collaboration with the development and other team members.

Also we will discuss the real-life issues that can arise inside such teams, for example:

• new analyst onboarding;
• knowledge transfer and management;
• stakeholder as a bottleneck;
• crossing the boundaries of the work of different analysts.

And we'll try to resolve them.