User stories are common in agile methodologies even though they are not an explicit part of the Scrum guide. They are short feature descriptions from an end user’s view and typically follow the format:
As a [type of user], I want [an action] so that [a benefit/a value].
User stories work well for many software teams, but I’ve always struggled with them. As a result, we’ve never become friends. I needed a pragmatic alternative to user stories for my individual product management approach. Why?
Firstly, I found them repetitive. I often had to use the same user persona, which created unnecessary overhead. It also felt artificial to always mention the persona in a robot-like way, just for the sake of the format.
Secondly, user stories lacked context. They didn’t answer critical questions about the problem. For example, where did it come from? Who identified it? In a remote work setup, this absence of context creates communication gaps and leads to costly iterations. Some team members used external tools and links to add more information. Others withheld details for direct discussions/chats or had their particular writing style for tickets (e.g. Jira issues). This inconsistency made things even more difficult with distributed teams.
Lastly, user stories needed to be more flexible for me. I wanted a simple format for any task, not just features or improvements. I am admittedly lazy (pragmatic 😎) in that respect. I like to use more natural language that mirrors typical team discussions – in a sense, how you would typically approach a team member to discuss a matter.
As a side note, I also noticed over the last decade that the idea of user stories simply doesn’t always resonate with teams of smaller companies accustomed to their unique way of working. That’s where the following format can be a valuable, pragmatic alternative.
The GPS Format as Alternative to User Stories
I tried job stories and a couple more alternative formats, but no template really sparked excitement. While reading books about general communication unrelated to product management, I stumbled upon the Goal-Problem-Solution (GPS) template. Here’s a quick rundown of the GPS format:
GOAL Describe the goal in one sentence. PROBLEM Describe the problem and share the context.
SOLUTION Describe the solution to achieve the goal.
This original concept is well explained in more depth by Chris Fenning, whose excellent book “The First Minute” I highly recommend. Chris’ pragmatic yet logical GPS template immediately clicked with me. After exploring the template further for various situations, I finally adopted the idea and applied it to my product management environment. Within a few weeks, it became my perfect replacement for user stories.
Let’s zoom into the GPS components and how I use them for writing Jira tickets:
GOAL – Describe in one concise sentence what you want to achieve with the task or the improvement. Make sure not to describe a solution already but the outcome. This sentence helps other team members to get the broader picture, i.e., why this ticket exists. Thinking again about the goal is also an excellent exercise for yourself.
PROBLEM – Share the context and describe the problem in more detail. For example, where does it come from? What is the status/situation/scenario, and who triggered it, etc.? Add whatever helps the reader, but filter to the minimum information needed.
SOLUTION – This section can outline a proposal and even include detailed acceptance criteria (to loop back to the user stories). If unclear yet or needs more discussion, use “TBD” (to be discussed).
Imagine a web-based graphics software where you log in through your browser (SaaS). The tool allows you to design illustrations in minutes through AI-generated templates. For the top area, we now want to improve how the logged-in user is displayed. Instead of showing only the name as an earlier cheap solution, the profile picture should be shown:
Now, we want to describe this improvement for the team. Coming back to the GPS format, this is how a potential ticket might be composed:
GOAL Let a logged-in freelancer immediately know which account is used.
PROBLEM We have a set of freelance users that register different accounts in our software: one free account for private use, and a paid one for their business clients. So far, we have used only the name as a visual indicator in the UI for the account. As a result, it can be unclear for such users if they are currently logged in to their private or business accounts. This problem has been repeatedly reported in public reviews.
SOLUTION Introduce the option to upload a profile picture. It allows such users to choose different images depending on their account (private/business): • Show the profile picture in the screen’s upper right corner • See attached mockup for a design proposal
All relevant information is in one place, neatly structured – ready for a chat or a more thorough discussion with the team. To me, that’s a decent and highly intuitive alternative to user stories.
This is how it looks in Jira:
The GPS format is particularly effective for remote teams and can also help lean teams that follow a rather engineering-driven development style. It provides a clear, organized summary of all the necessary information for more precise async communication.
I love that it’s generalized by serving as a one-size-fits-all template for new features, technical tasks, and even non-technical internal tasks for QA or marketing.
The best part: the whole thing flows and is lightning-fast 🚀
Once you start typing the bold subtitles into your ticket description (GOAL, PROBLEM, SOLUTION), the corresponding information adds itself almost automatically due to its logical structure. As a solo PM of several teams, this template is incredibly helpful to write and understand tons of tickets quickly.
So, let’s explore more ways to use the format:
Technical Tasks
For highly technical tasks, this approach is also a lifesaver. It simplifies communicating what the task entails and why it’s necessary. Complex task descriptions with many technical terms immediately resolve into an easy-to-understand piece of work!
Here is an example:
GOAL Avoid severe security issues introduced by the JavaScript framework J-ABC.
PROBLEM Unfortunately, our developers reported that J-ABC is now officially tagged end-of-life (EOL). It no longer receives any security updates. This results in a serious attack surface and represents a substantial threat to our entire product offer. We urgently need to discuss countermeasures that help us now, while a completely new technical solution is needed in the long run.
SOLUTION As discussed earlier with the team, we will manually patch issues on a weekly basis that are still reported here. In parallel, we will start replacing J-ABC with a new framework by the end of Q3 this year. The most promising candidate is J-XYZ.
Both the goal and the problem context provide clarity – not only to fellow team members but also to non-technical stakeholders (e.g., management or sales).
I often have to pull other stakeholders into an ongoing task at a later stage, where I ping them through the ticket (@name). They can scan the GPS ticket description and immediately understand the issue. So, you also protect their precious time when they are forced into a context switch 👍
Internal Tasks
As a generalized template, you can also describe any internal task with it. For instance, we can also use it to describe internal procurement tasks clearly, such as the need for new hardware:
GOAL Accelerate the creation and publishing of YouTube tutorial videos.
PROBLEM Peter’s notebook is 8 years old and super slow. Editing longer videos in a reasonable time is impossible, i.e., rendering the video takes ages. This is quite expensive and annoying since it means a substantial waiting time, so he is blocked. We have checked if more modern hardware is left in the company, but we have nothing in stock.
SOLUTION Procure a new notebook asap! After an internal discussion with Peter, we recommend the following: • Apple MacBook Pro 13’’ • 16 GB RAM • 1000 GB SSD • Shop link for more details on the exact model
Restructuring Content
Finally, and more as a remark, this template can be a powerful tool for restructuring existing content, such as messy ticket texts or tasks that are hard to decipher. You need to copy & paste existing sentences into the corresponding GPS sections to build logical content. Typically, this takes only a few seconds.
Tiring long texts with an unclear structure vs. restructured content for fast reading.
So, the template works wonders, even when quickly applied to previously chaotic task descriptions (well, I am guilty of creating such content).
Maximizing Remote Work Benefits
Over time, I’ve integrated this template into all of my tasks and teams. I did that slowly and carefully, constantly checking with the people to see if things made sense for them.
And what are the results?
Well-written communication is what has finally enhanced autonomy and efficiency. The number of communication loops has been minimized in my remote work environment. The structured information makes things clear for all parties.
I’ve always championed high autonomy and individual flexibility within remote teams. The desire to optimize everyone’s focus time (including mine 😉) and accommodate personal schedules and lifestyles has been a constant theme throughout my product management career. Effective information exchange is critical to making this work.
For example, arranging direct meetings with distributed teams can be a pain, if not entirely impossible. Also, given my role’s specific demands, I can’t fit ceremonies such as daily standups with all the teams into my schedule. Instead, I heavily rely on async communication, mostly chat and ticket comments. In that particular context, the GPS format really shines ☀️ and provides immediate clarity for everyone.
I do not push other team members to use this GPS format. Instead, I invite them to experiment with it. The results are often stunning and a joy. Even without comprehensive instructions, the understandability of ticket descriptions increases from one day to the other.
Wrap Up
The GPS format helps me as a PM to sort out my thoughts and improve my communication in a semi-automated, fun way. I have drastically minimized my mental efforts to process and structure complex business information — with an embarrassingly simple template 🫣
So, I am just a fan of minimalist, simple stuff. And the GPS format is exactly that: simple. The whole idea is not rocket science, that’s for sure. But … it works like a charm.
Through my years as a product manager, this format as an alternative to user stories has emerged as a highly effective instrument in my toolkit. The simplicity and intuitive nature have revolutionized how I describe tasks for myself and others. The approach is straightforward, logical, and adaptable.
I can’t imagine going back to user stories.
So, what do you think about it? Does it also make sense to you? Reach out to me and let me know 🙃
Book: Minimalist Product Management
I have compiled more details of this concept and my experience with it into a practical guide for PMs and lean remote teams. The ebook shows you how to experiment with the GPS framework in your organization. The step-by-step guide also provides numerous GPS examples and expands on using the template to describe entire product initiatives.