> For the complete documentation index, see [llms.txt](https://stepsize.gitbook.io/stepsize-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stepsize.gitbook.io/stepsize-documentation/team-and-collaborators/talking-to-your-product-manager-about-stepsize.md).

# Talking to your Product Manager about Stepsize

**Stepsize works with organisations like yours to unlock unprecedented improvements in velocity, quality and employee retention.**

## **Proving impact with Stepsize**

You understand the transformative power of tracking issues directly in the codebase.

But how can you get buy-in from your product manager?

Getting the most out of Stepsize requires both the **tool** and a **process**.

In this guide, we'll describe a tried and tested experiment that you can run with your team to prove the impact of Stepsize in **driving behavioural change in the way your team creates and resolves issues**.

## **Expected results from your experiment**

On average, we expect that over the course of an experiment, engineering teams will...

* [x] **Create 10x issues** 👉 Visibility
* [x] **View 20x issues** 👉 Awareness
* [x] **Resolve 10x issues** 👉 Actionability

## **The experiment**

> ***Track one, fix one.***

1. Select a time period for your experiment. This could be 1-2 weeks or a sprint, for example.
2. Get on the same page. Hold a meeting to kick off the experiment.
3. **Track one**. Each engineer documents at least one new issue over the time period.
4. **Fix one**. Collectively agree on an issue to resolve as a team. We suggest holding a short meeting to do this.

{% hint style="info" %}
If you can, record anything you observe which might be relevant to make your case, such as behavioural changes in the way engineers use Jira.
{% endhint %}

## **Reviewing the experiment**

* **Visibility** - How many issues got created? How does this number compare to your normal number when using your standard issue tracker alone?
* **Awareness** - How many issues were viewed? How does this number compare to your normal number when using your standard issue tracker alone?
* **Actionability** - How many issues did you resolve? How easy were they to prioritise (e.g. using the codebase visualisation – *for more information, see our guide*)

![Using the Visualisation tool in Stepsize](https://res.cloudinary.com/drvhrxrne/image/upload/v1671455776/samples/product_guides/visualisation_zoe31i.gif)

What qualitative data do you have? For example:

* What feedback did the engineers have?
* What changes did you observe in the quality of issues?

## **Talking to your Product Manager**

You've conducted and recorded your experiment. Before you talk to your Product Manager, ask yourself...

1. *Did the experiment improve Jira participation (or whichever tool you use)?*
2. *Did the experiment help to expose technical risks? How?*
3. *How will continuing using Stepsize with a process like this make it easier to plan predictable sprints?*
4. *How will continuing using Stepsize with a process like this increase sprint throughput?*
5. *What labels might be useful for your team? e.g.* `morale`, `velocity`, `security`...

## **We can help**

**Stepsize works with organisations like yours to make the most out of your engineering resources and manage tech risk better**

## [**Set up a call with us**](https://meetings.hubspot.com/alex527/tech-debt-management-with-alex-stepsize) 🤙