top of page
  • Writer's pictureValentina Zanetti

The Agile Alchemist's Solutions for Products

The Agile Alchemist's recipes to Product Solutions; how to maximize Product value and resiliency!


Alchemist's Cauldron Brewing Product Solutions

Today we're delving deeper into the Agile Alchemist's methodologies for product ownership, and we'll touch on the 'why', 'who', 'what', 'how' and 'when' behind building quality digital products and maximizing their business value and resiliency.


Let's assume, for the purposes of this exercise, that your organization has already implemented some form of business agility and that you are working with a more-or-less agile framework. Let's assume you've been tasked with finding a solution for a new product or product feature. Let's assume you've gathered a cross-functional team of experts that will be delivering the work.


Where to Start? Identifying the 'WHY' Behind Your Product


"Let's start at the beginning, a very good place to start"

Julie Andrews, The Sound of Music


Whenever you are tasked with creating a new product, be it a simple corporate website, mobile app, ERP system, or something very complex, you should always approach the challenge by asking 'why'. Why is what you're creating needed? Why are doing what you're doing?


It always comes down to one of the two reasons:

  • Solving a problem

  • Achieving a goal


Scenario: For the purposes of this exercise, let's explore something relatively simple and say a you need to create or redesign a corporate website. The first thing you should ask is why. What are you hoping to achieve with this endeavor, what behavioral shift do you want to get from your end-users? If the main goal is to increase sales leads, you might focus more on the User Journeys. If the current system is difficult to use for editors, the focus might be a more user-friendly CMS. If the goal is to improve digital branding, the focus might be SEO-oriented implementations, like blogs or communities. As you can see, the motivations behind a website can differ greatly, and the actions for these motivations are exponentially more different. And that's just for a 'simple' website.


Whatever the situation, you need to be fully aware of the main purpose of your efforts, because trade-offs will need to be made from the very beginning. Make sure to define this with all relevant stakeholders, and use it throughout your efforts as a continuous guiding reference and a North Star.



An Alchemist's Compass


Make the 'WHY' Transparent and Obvious at all times


Defining the 'why' is your first step and your foundation, and probably the most important step in creating a product. It's something that you will need to rely on throughout the development of your product or product feature. That is why it's important to make it completely transparent, and, more importantly, clarify how the efforts align with the purpose and the 'why'. Otherwise, you risk losing yourself in a sea of user stories and tasks and forget to prioritize for purpose.


Scenario: You've concluded that you need a website redesign to generate more viable sales leads. Digital branding and CMS user-friendliness is also goals, but secondary. You're now in your third sprint, and there are probably a lot of epics and user stories in your backlog by now. There are several user personas and, therefore, several user journeys to consider, the designs are intricate in order to improve visual branding and content editor stakeholders also need to be taken into consideration, too. Before you know it, you start making compromises to the primary goal in order to accommodate secondary goals or, even worse, adding unnecessary features that hardly have any impact at all because they 'look good'.


Let's not be fooled, this is a difficult balancing act, but a necessary one, if you strive to deliver value. Here are some of the tools you can use to visually map out the purpose behind your efforts, and make sure you are doing work that aligns with the 'why':


A prominent Product Goal Statement

Define a Product Goal Statement in one sentence and paste it EVERYWHERE. Literally EVERYWHERE you can. Pin it in all the Teams/Slack channels, make it a header to all Confluence pages, make it part of the Jira User Story template, remind everyone of it daily, if necessary.


Lean Product Canvas

This is a simple tool to make the actions and their impacts clear, as well as all the related metrics, customer segments (user personas/actors), channels, cost structure and revenue streams. Make it available to everyone working on the team, including the junior members, it will provide clarity and purpose to everyone, and enable T-skill shaping


A High Level User Journey

Map out a high-level User Journey of how you'd like your end-users to behave, which actions you'd like them to take, and what is the desired end-result of the user journey, this will make it clear what is the core User Journey.


A High Level Feature Map

User Story Mapping is generally a great tool to show how the work items align with the User Journey and the goals that you're trying to achieve, and how everything tracks back to the source, or to the 'why'. If you start mapping the work items out on a higher level, right from the start, it will be much easier to map the smaller tasks later on, and greatly facilitate prioritization when there's a lot to be done.


When you have your 'why' established and a framework to implement this cognition across the implementation team, you're ready to tackle the 'who', 'what', 'how' and 'when'.


Identifying 'WHO' Your Product Solution is for


User persona identification is mostly done by people in marketing domains (you should have them on your teams, too!), but I'll leave discussing the tools and methodologies used to identify them for professionals specialized for them.


I will, however, note that end-user personas aren't the only actors/users of your product. Users/Actors can be content strategists and editors, sales department personnel, even systems, and even, yes - developers. It's up to the product owner to identify which actors/users are affected by or affect the product.


Scenario: You're working on your website project and, since sales leads are your main goal, you need to consider all the players involved in the equation. So, for your project, in addition to end-user personas (like 'Lucy, 28, entrepreneur' or 'Mark, 32, sales specialist') defined by the marketing department and the question of how you might facilitate their user journeys, you also need to consider the digital marketeers who need to get data about the parts of the user journey where users most frequently abandon it, content editors and how they might be able to more easily manage and optimize this journey, the recipients of the notifications about new leads generated and how they interact (if at all) with your websites, the possible CRM, PIM or DAM systems you're integrating with, and ultimately, the development team and the best way to make the implementation easily manageable and scalable.


There isn't really a tool for identifying all the actors on a software project (at least that I know of), and it's best to include representatives from all product domains to contribute. Some user journeys will include more actors than others, and this sometimes need to be identified on a more granular level, but it's very useful to have all the actors and their user journeys in mind when creating a product. Again, if the purpose of the product is aimed at a specific group of actors (most frequently - end-users), you will need to prioritize the core user journey.


Now 'WHAT'? 'HOW' to Bring Your Product Solution to Life


Now that you know the purpose of your product, who you're building it for and who are the other users of your product, you can start defining what to do.


Whenever you're figuring out 'what' you're going to do to solve a problem or achieve a goal, you need to at least have a high-level idea of 'how' you're going to do what you want to do. To accomplish that, you need to have a cross-functional team working on a solution from the get-go. Production line work and hand-off from one team to another to another is not going to get the desired results. You will need to include everyone in determining what to do and how to do it from start to finish. Otherwise, you'll be losing so much time in back-and-forth communication, documentation, validations, corrections and just plain rework.


Scenario: You have your 'whys' and 'whos' defined, and you are finally ready to start creating an actual backlog for your website. You've taken the inputs from your stakeholders and from the marketing department, and now you're working with content strategists and UX designers on defining your core user journey and it's belonging features. They finish their part of the work, define a user journey, create a UX experience for the journey and the core features are already there, ready for the designer or maybe even for the development team. You bring this to the designers or the development team, they start shaking their heads, saying 'this won't work at all on a website', 'this is going to cause issues with XYZ', 'the performance here will be poor', and a whole plethora of other issues. Then you take all their feedback back to the content/UX team, whose budget, by the way, you've almost completely depleted, and you're noticing already that you're going to be late with a delivery even though haven't even started!


To avoid the above scenario, always make your teams work together from the beginning. It will bring a multitude of benefits, including but not limited to:


🔺Early feasibility validation

🔺Quicker risk identification

🔺Reduced hand-off times between domains

🔺Less documentation efforts

🔺Better familiarity with the product on all sides

🔺Simpler (and quicker) technical implementation

🔺More invested team members

🔺Better team collaboration

🔺Learning opportunities to shape T-shaped skills


These are some of the tools and exercises you can do with your whole team:


𝐌𝐢𝐧𝐝 𝐌𝐚𝐩𝐩𝐢𝐧𝐠

This is a great brainstorming tool which enables building on each-other's ideas. Everyone can contribute an idea of their own and also expand on other people's ideas. The end result will give you a good grasp on which direction to take and the best ways to go about it, AND you'll get an idea of the effort and expense of the generated ideas right from the start.


𝐉𝐨𝐮𝐫𝐧𝐞𝐲 𝐌𝐚𝐩𝐩𝐢𝐧𝐠

Try to do this cross-functionally as early as possible. Although it may not be necessary for a technical representative to be present for the high-level User Journey Mapping, it will provide context. For the more granular User Journeys, mapping them out together with the whole team will give you a good overview of the pain points and the opportunities to improve them, and the technical team can provide their insights on where you can reduce expenses and gain value quickly.


𝐑𝐚𝐩𝐢𝐝 𝐩𝐫𝐨𝐭𝐨𝐭𝐲𝐩𝐢𝐧𝐠

Creating low-fidelity wireframes and flows is a great exercise to validate an idea from multiple standpoints. And who better to include in assessing the validity and feasibility of an idea than the people who will be delivering it? It will also save you a lot of time on documentation, detailed wireframes and endless discussions on technical implementations, everyone will be familiar with the general idea of the prototype.


𝐒𝐂𝐀𝐌𝐏𝐄𝐑

This acronym stands for Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, and Reverse, and you can use this exercise when you already have a few rough ideas and/or prototypes, to see how to streamline, simplify and improve them, and again, technical expertise in this effort is priceless and saves a lot of time.


An Alchemist's Blueprint

What About Deadlines? Dealing With the 'WHEN' of Product Solutions


You will often hear that agile doesn't deal with deadlines or constraints, but it's quite the opposite. Agile is about maximizing the value delivered within these constraints, deadlines and due dates being a big part of the picture.


So the main point of focus when dealing with deadlines in an agile environment is: prioritizing.


Scenario: You've developed several features for your website, the deadline for Go-Live is increasingly closer, and you're receiving feedback from a lot of sides and it's getting harder and harder to identify the priorities. The QA is reporting every misaligned pixel or color discrepancy, the designer is asking to create an extra layout for the image-text module because it's important for the UX, the content strategy team is asking for a deepening of the navigation, the marketing department is asking for more integrations with their CRM, the developers are asking can they change how they implemented a feature, because they found a better way, and you don't know where to turn next. What to prioritize?


When push comes to shove, when your team members and stakeholders start seeing the first results of your efforts and they start giving you feedback, it's easy to get overwhelmed and use sight of the forest from the trees. This is also a crucial moment to refer back to the Product Goal Statement, and see how each of the demands tracks back to the source.


Consult the workshops and the visual maps created in them to determine the priorities:


🔹Consult the Product Goal Statement to see how the new requirements align to it

🔹Consult the main User/Actor of the product, the one the main product goal is tied to

🔹Check your Impact Mapping to define the desired impacts on the main Actors

🔹Check the User Journeys mapped out to affect the Main Actor

🔹Identify which of the new User Stories can contribute to the User Journeys for which Actors

🔹Validate the impact of the User Stories to the Actor's behavior


To help determine the primary high-level objectives for complex projects/products, use a 𝐂𝐨𝐬𝐭 𝐨𝐟 𝐃𝐞𝐥𝐚𝐲 calculation, where you will be able to define not only what will generate the most value, but also where you're likely to lose the most if it's deprioritized. When you know which are the most impactful and most complex parts of the workload, simply 𝐞𝐚𝐭 𝐭𝐡𝐞 𝐟𝐫𝐨𝐠! 🐸 (Before you go to a French restaurant for some fried frog legs, 'eat the frog' is an expression that refers to tackling the most complex issue first). Prioritize the rest of the issues per the same principle in a simple must-have, should-have and nice-to-have pyramid that you can plan into Sprints later.

Scenario: You've reviewed the feedback from your website's development team and your stakeholders, and you've checked these requirements quickly against the mapping you've already done. The main goal of this website is to generate more viable sales leads. You'll soon come to realize that fixing a color or alignment discrepancy on a module will not contribute to the Core Journey, and it's not a disfunction that is likely to cause users to abandon the journey, so you deprioritize it or remove it from the backlog completely. You check the Content strategist's suggestion to deepen the navigation against the core user journey affecting the main actors group, and you determine that additional navigation levels will not contribute to optimizing it - the user journey is already easily accessible and intuitive. The change the technical team suggested will facilitate managing the website content for content editors and it will also make code maintenance easier, but it doesn't contribute to the core journey and doesn't promise to save any significant time in the near-future development, so it can be prioritized for after the Go-Live, as it is not part of the Core Journey. Adding more CRM integrations, however, will allow sales personnel (an actor in the story) to document and follow-up on leads quicker and with better quality, which - although maybe not on your website's core journey - is important for the overall goal - generate more viable sales leads! You decide to go ahead with the CRM integrations and adding additional critical features! Next Sprint Review or any other feature review session, you gather new insights and prioritize again.



The Alchemist Frog


Conclusions


In Conclusion, keep you product goals clear, close and visible. Map out who you're going to be reaching out to, with what and how, and prioritize the most impactful and most complex issues first.


And always, always remember, 𝐚𝐧 𝐚𝐠𝐢𝐥𝐞 𝐛𝐚𝐜𝐤𝐥𝐨𝐠 isn't a set list of features that must be implemented divided into Sprints, it 𝐢𝐬 𝐚𝐧 𝐞𝐦𝐞𝐫𝐠𝐞𝐧𝐭 𝐩𝐥𝐚𝐧, 𝐛𝐚𝐬𝐞𝐝 𝐨𝐧 𝐧𝐞𝐰 𝐟𝐢𝐧𝐝𝐢𝐧𝐠𝐬, 𝐧𝐞𝐰 𝐞𝐦𝐞𝐫𝐠𝐞𝐧𝐭 𝐭𝐞𝐜𝐡𝐧𝐨𝐥𝐨𝐠𝐢𝐞𝐬 𝐚𝐧𝐝 𝐜𝐨𝐧𝐬𝐭𝐚𝐧𝐭 𝐨𝐩𝐭𝐢𝐦𝐢𝐳𝐚𝐭𝐢𝐨𝐧, and when dealing with deadlines 𝐚𝐥𝐰𝐚𝐲𝐬 𝐫𝐞𝐩𝐫𝐢𝐨𝐫𝐢𝐭𝐢𝐳𝐞 the work against the objectives! Make sure to get the most important things done well enough, don't aim for perfection, and forget about the fluff.

58 views0 comments

Recent Posts

See All

Comments


bottom of page