Product Goals for Power Platform and Dynamics 365

[00:00:00]Welcome to Amazing Applications. This is the podcast for Microsoft Business Applications creators building amazing applications that everyone will love. 

Hello, I'm Neil Benson and this is the Amazing Applications podcast. Where our goal is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks, and create amazing agile Microsoft dynamics 365 and Power Platform applications that everyone will love.

Humbled and honored is such a cliche that it's probably got its own hashtag on Twitter. And I know Joel Lindstrom has a humbled and honored t-shirt. But I received my 12th Most [00:01:00] Valuable Professional award from Microsoft this week. So I guess I'm your humbled and honored podcast host. 

If you're passionate about contributing to our community. Are prepared to really up your game, and are looking for an MVP to mentor, and eventually to nominate you, let me know. I've mentored lots of community contributors who've also become humbled and honored, and I'd love to make some time for you. So send me a LinkedIn message and we can set up a call. 

 In the last episode, we looked at ten potential candidates for the product owner role in our scrum teams building Power Platform and Dynamics 365 applications. In this episode, we're going to continue the product owner topic by helping the product owner set a product goal.

You'll find show notes for this episode at customery.com/041. 

[00:02:00] Goal-setting has always been part of Scrum. At least far back as I can remember. Sprint goals are short-term goals that the scrum team agrees on at the start of each iteration to guide our work for the upcoming sprint.

Sprints are short. So naturally, sprint goals are short term goals. For a while there, the Scrum Guide mentioned release goals as a way of framing medium-term goals, but releases and release goals got dropped from the Scrum Guide sometime ago, as Scrum became popular outside of software development, where teams don't really have releases. 

With the 2020 edition of the Scrum Guide released late last year we have product goals.

Now the Scrum Guide leaves it open to interpretation as to whether the product goal is an overarching long-term goal for your application or whether it's a medium-term goal that gets [00:03:00] refreshed from time to time as we reach our current product goal. 

Scrum is a framework after all, and it's not a prescriptive methodology. It's only got a few hard and fast rules. For example, every sprint should have a sprint goal. But there are no rules yet, not many at least, regarding product goals. The Scrum Guide says that "the product goal describes a future state of the product. It is the long-term objective for the scrum team". To me, that makes it sound as if it is the single long-term product goal, similar to a product vision statement. 

But then the Scrum Guide goes on to say, "The entire scrum team is focused on one product goal at a time". Now that makes it sound like there's a series of maybe medium-term product goals that we achieve in sequence, similar to the old release goals. 

[00:04:00] So how should we treat the product goal when we're building Dynamics 365 and Power Platform applications?

I like the work that Roman Pichler has done framing product goals and setting them within a goal hierarchy. It goes like this. At the top, we have a product vision which describes the ultimate purpose of our application. The impact it will have. 

From that product vision, we have user goals and business goals.

User goals describe what your application's users want to achieve with the application while business goals describe what outcomes or business benefits the organization wants to achieve by deploying this application. 

From user goals and business goals, we get product goals. So in Roman's hierarchy, they sit third. The third tier of his hierarchy. Roman suggests that your product goal should describe a specific and measurable benefit or outcome [00:05:00] that your product should create in the medium term. He suggests two to six months as a guideline. So we're setting a new product goal every 2, 3, 4, 5 or 6 months. 

If your product goals are derived from a combination of user goals and business goals together, then you'll probably have a compound product goal that's a bit of both as well. 

From your product goals, your sprint goals will spring to describe your short term objectives over the course of the next iteration. In Scrum, those iterations are called sprints and are up to one month long. One-week or two-week sprints are the most popular with my business applications scrum teams.

So Roman's goal hierarchy has got four levels: product vision, user and business goals, product goals, and sprint goals. 

Let's try and bring this to life with an example from a Dynamics 365 or Power Platform project. 

[00:06:00] Here's an example product vision. The vaccination management application will enable 5 million people to be vaccinated by December 2021.

That's our long-term overarching product vision. It's supported by a number of user and business goals. Here's some examples. 

User goal one. Book two appointments for participants aged 18 and upwards based on cohort priority. 

Goal two. Book 72 vaccinations per clinician per day. 

Three. Support individual appointment booking. 

Four. Support mobile clinic bookings.

Some business goals might be:

Complete the two-dose vaccination of cohort one by 31st of March, cohort two by 30th of June. Cohort three by 30th of September, and cohort four by 31 December. 

Business goal number two. Deliver 90% of available doses. 

Business goal three. [00:07:00] Report on completed first-dose and second-dose vaccinations daily by cohort, by location, by clinician and by vaccine type and 

Business goal four. All vaccinations are recorded on My Health Online individual health record management system.

So from that, we might have some product goals in a sequence like this:

Product goal one. Book individual appointments. 

Number two. Optimize doses, and provide reporting. 

Number three. Book mobile clinics. 

That product goal number one, to book individual appointments, might be broken down into sprint goals:

Sprint goal one. Registration online, by phone, by general practitioner, and through walk-ins.

Sprint goal two. Cohort questionnaire and segmentation.

Sprint three. Might have a goal of book first appointment, and 

Sprint goal four. Might have a goal of booking the second [00:08:00] appointment. 

So I hope that helps you visualize how you can use product goals as a medium-term goal to work towards every few months that connects the short term sprint goals to the long-term user and business goals, which in turn connect to the overarching product vision.

In almost all the Dynamics 365 and Power Platform apps I've worked on, the organization has a business case that describes their goals. Not always in the same format, I've just outlined or with the same four-tier hierarchy or titles, but close enough that I think you could translate those business case goals into Roman Pichler's four-tier hierarchy. 

 I'm a big fan of emergent requirements and emergent design. As opposed to upfront requirements analysis and application design. We let the detailed requirements emerge as the application is being developed and we design the features just in time to [00:09:00] start developing them. This emergent analysis and design practice supports agility because we don't waste lots of time analyzing and designing everything upfront.

If we did that and the goals or priorities have changed, then all the analysis and design effort that you've done upfront might be wasted. And I think emergent analysis and design practice compliments the goal hierarchy really well. At the outset of our project, we established the project vision, the user goals and the business goals.

We usually know enough to set our product goals for the next 12 months. Maybe even longer, depending on your project. And we can sketch out the features that will be needed to support each of our product goals. And we can describe those features as epic user stories. 

So now we have a roadmap of features or epics that support our product goals that will deliver our user and business goals that will help us achieve our vision over the next [00:10:00] 12 to 24 months. And we've achieved all of that without describing every single requirement or designing any features. 

How do product goals relate to product backlogs? 

The 2020 Scrum Guide says that, "Product goals are in the product backlog and that the rest of the product backlog emerges to define what will fulfill the product goal." Wow, what does that mean? 

Well, I've seen some enormous product goals in my time. Thousands and thousands of individual requirements, each captured as a separate user story with a title, persona, description, value statement, and even some acceptance criteria. They probably took months to write all those requirements. So much wasted effort.

I remember Scrum trainer, Ryan Ripley, asking an audience about their oldest product [00:11:00] backlog item. And one developer had a PBI that was nine years old. That's older than my son. It was a nine-year-old PBI. There's no way a nine-year-old PBI is ever going to get prioritized and done. If no one's loved it enough for the last nine years, no one's going to love it enough in the next nine years. Ryan's a fan of deleting PBIs that are that old and that low a priority. De-clutter your backlog, de-clutter your mind! Marie Kondo style. 

Instead, we can use product goals to summarize all those requirements that we might want to deliver six or more months from now. We simply put the goal into the backlog and as we get higher priority items done and a product goal rises towards the top, we split it up into features, then epics, then individual product backlog items that align with our sprint goal. Just in time to start turning them into increments. 

[00:12:00] I'm a big fan of product goals. I like how Roman Pichler has given them structure and positions them between a product vision and our sprint goals. I've included links to Roman's book, 'How To Lead In Product Management', and some of his helpful articles in the show notes at customery.com/041. 

What do you think about product goals?

I'd love to hear your examples. Leave a comment under this episode's post on the Amazing Applications page on LinkedIn. And let me know how you're using product goals or any questions you have about using product goals in your Dynamics 365 or Power Apps projects. 

While you're there, remember to follow the page so that future episodes appear in your LinkedIn feed, or better yet follow the Amazing Applications podcast in your favorite podcast app so the episodes are downloaded to your device as soon as they're published. You'll find the show in Apple Podcasts, Google Podcasts, [00:13:00] Spotify, Amazon Music Player, Audible, Overcast, Pocket Cast, iHeartRadio, Castbox, Podcast Addict, Podchaser and lots and lots of others. 

And if you listen to podcasts on Pandora, then we're hoping to be listed there soon as well. Turns out Pandora blocks log-ins from Australia. So I had to work around that one with a VPN, but hopefully I'll be on there soon as well. 

Thanks for listening. Go and use product goals. I really appreciate you until next time. Keep sprinting.