What discovery looks like for internal products.

I like attending conferences because they offer a bit of insight into what others’ worlds look like.

The insight doesn’t come from the speakers on stage, they come from the conversations at the lunch table. Although ironically, this story starts at the speaker’s dinner table the night before a conference.

I was at a conference focused on software development in general and the majority of the speakers at the table I sat at came from a software development background. The conversation was wide ranging, but one particular topic stood out:

How rare it was for developers to speak to the people who used the software they built.

That topic stood out, because I had just lived the exception that proved the rule a couple of days before.

Move the toggle

The team was having a backlog refinement discussion and we got to this backlog item with this request:

As a Manager, I need the Thingamajig toggle to be moved on the page so it is not under the SNAFU toggle, to prevent accidentally SNAFUing the program.

I changed the persona and toggle names to protect the innocent.

Our initial question was where should we move the toggle to. So we sent a DM to the SME who originally requested the change, and asked where they wanted it moved to.

The response:

I do not have a preference, let me check with the other teams that use this page to see if they do.

Our interpretation:

I won’t know until I see where you put it.

We kept discussing it for a couple of minutes with that casual banter that teams use to throw ideas out when they don’t have any clear direction. Then someone said, “geez, it’d be nice to see how people use that page.”

Yes, yes it would.

We set up a couple of quick screen shares where someone from each team that use the page walked us through their process.

We found out that the team that actually flips the toggle only visits the page in question to flip that one toggle. We also found out that there needed to be data in a bunch of the other fields on the page in order to save their toggle flip.

We discovered that we could save that team some time and address the original problem by moving the toggle to a completely different page.

Something we wouldn’t have realized had we not seen the teams in action.

You can observe a lot by watching. – Yogi Berra

Want to hear about AI?

We interrupt this regularly scheduled InsideProduct post to let you know about a poll over on LinkedIn

There are a lot of people talking about AI, but I wonder how many people want to hear about AI. I figured this was a good way to find out, and the more responses I get, the more I’ll trust the results.

So please go leave your thoughts now. We’ll wait for you…

And now back to our regularly scheduled post.

Discovery instead of gathering requirements

Our initial question – where do you want the toggle – is a perfect example of what you’d ask when you were gather elicit requirements.

And the response you’d get back is likely what Henry Ford would’ve had in mind had he actually said the faster horses comment.

When you work on internal products, you’ll likely get requests handed to you in the form of a solution.

Ideally you want to dig into that solution to uncover the underlying problem (that’s certainly what trainers like to proclaim from their ivory towers). But there’s pressure to just make the change.

So your first reaction is to ask for more details to flesh out the backlog item and identify useful acceptance criteria.

That can easily turn into movie phone requirements gathering.

As we found out with the toggle shuffle, its possible to get more context – and perhaps even learn the underlying problem – without asking what problem your SME is trying to solve.

All it takes is watching people use your internal product in the area where they identified something that needs to change. As you watch, ask them about the steps they take, ask them about why they do things the way they do them, and ask them about what pain the thing they asked you to change causes.

In other words ask questions about what they do (or can’t do), not questions about what they want.

Getting that kind of context give you a much richer appreciation for the change and will often help you identify a simpler, yet more elegant solution, than what your stakeholder originally asked for.

Like moving the Thingamajig toggle to a completely different page.

This is discovery

Note that we didn’t proclaim a discovery phase. We didn’t have to ask for permission. We didn’t write a separate discovery story…

Sorry, I just threw up in my mouth a little bit there.

We reached out to our stakeholders, like most internal development teams should be able to do, and instead of subjecting them to some sort of Spanish Inquisition…

…we showed interest in their day to day processes and challenges.

Not to mention, we learned a lot more than had we simply asked what problem they wanted to solve or where to put the toggle.

No comfy chairs required.

And there was no difficulty getting in touch with our users. In fact, that’s one of the benefits that people working on internal products have. Their users are a lot easier to talk to.

All you gotta do is ask.

Then again, maybe I’m in a unique situation. I’d be curious to hear if you find it fairly easy to get in touch with your users or if you’ve run into difficulties.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent