When I’ve started my career in IT in 2012/2013, most of the initiatives, projects or products had been delivered in big scale. After a long time of analyzing all Customer needs, collecting tons of tiny details, constant discussions on scope and price, developing, testing – we had the most scary event, called production deployment (often on weekends, meaning that that will be no sleep for at least 48 hours). I don’t have a data to prove it, but based on my experience I bet that average project time back then was at least a year – and it had nothing to do with the company you have worked for – because the whole industry was delivering like that. So if everybody was doing it, why was it bad?
First – our Clients had no idea how their product will fit the need of their Customers until we release it. They paid a ton of money for something, which in a year later might be totally unnecessary for the market. I witnessed it once, working on a Product which after more than year had not been even released (the Company changed the board of directors, with totally new vision on who will be their Customers and how the services should look like). Second – if analysts misunderstood the Stakeholders, or Stakeholders decided on changing the scope of the release in the middle of software delivery process – we needed to change the whole architecture and rewrite half of the thousands of code lines. I also had a situation like that, where after seven months of work on Integration Architecture, one meeting resulted in redesigning the biggest part. Of course it was affecting the final price, which might affect the whole business case at the end of the day. It is not that we didn’t tried to build adaptive architectures, but having hundred of user stories written on the same level of release priority, we were only guessing which requirements of functionalities were written in stone and which one should be easily changed. Big backlog sold on fixed price had often only one priority level – urgent.
Initiative after initiative, the industry came to a conclusion, that in a changing business environment, we also need a change of approach for building Software Products. Agile Manifesto started to be popular on the market – and both us, Engineers and Customers, understood that we need to release small portions of features frequently. We also noticed, that it is also a way to finance software even if it’s not yet finished with 100% of planned functionalities. This approach also presented an old-new problem, which needed to be addressed – what is actually the value proposition and crucial customer needs, which we need to support with our software? What are the essentials of our software? What is needed on the market right now, so once we miss it – our product will no longer be valuable? How to deliver a Minimum Valuable Product on time, on schedule, on budget – which will actually make sense for our Customers and allow us to make next decisions? I can think on only one answer to all of those questions – you need to agree on priorities, focus only on them; shape them to manageable backlog, and hire a Team which will deliver it. Here is my instruction for you how to build a good backlog – decomposed to five simple steps and bunch of market-proven techniques which will help you do it.
Facilitating the Backlog Formation
I recommend that Facilitator and Product Owner will be different personas. Product Owner should focus on substantive aspects of the new Product, while Facilitator should focus on flow of interaction, discussion – and asking right questions to the Product Owner and the Team. Facilitator needs to be experienced in both Product Design and Technology aspects. It can be somebody from the outside of the Team – so each Team Member focuses on the Product Vision, not on proper timing or techniques itself.
#1: Define the Vision and the Customer.
The only reason we build a software at all is to satisfy our Customer need. Yes, only – if there are other reasons, you are probably doing it wrong (R&D is also to satisfy the Customer, but later – DevOps tools setup as well, just the customer is the developer). There are of course some side-affects of building and running the Software (like Engineers satisfaction, experience gathering, playing with tech) – but they cannot be more important than our Customer satisfaction. So the first questions we need to ask ourselves are – who is our Customer? What segments of Customers we are the most interested in? What are our Customer needs? How do we know that? Can we fulfill them? Selecting and understanding the Customer is a must have to build a backlog, which will make sense.
If we know our Customers – we can think a bit of what we can do to make them happy. What can we build? How is it different than existing products on the market? Who are our competitors? Who are our potential partners? How are we going to make money on our proposal? What are the risks? How are we going to reach the Customers with the Product?
![](https://khalasa.com/wp-content/uploads/2022/06/vision-1024x447.png)
You are now probably thinking: I think I’d rather discuss the vision with Business Strategists, not Engineers…right? Or you might be an Engineer, who is asking now: I though this blog is about IT – so where is the IT in it?
If you do – let me assure you that situations described in the introduction to this post, where I’ve mentioned a large-scale projects, with tons of analysis, coding, testing – to finally not deliver anything because of missed opportunity or to deliver something which does not satisfy customers at all – appear exactly because no engineer was invited to decision making processes, where the essentials of Customer needs and market situation had been discussed.
Engineers are not business experts, that is a fact – but they understand the limitations and possibilities which technology brings to the table. They are also perfect people to decompose a need into deliverables. Also, most of the engineers are a Pareto Rule fans (20% of functionalities will bring 80% of benefits). So if Engineers understand the Customers, you are going to have the architecture which will reflect the dynamics of the Customer. And this is exactly what you need if your product will be evolving.
Some remarks for the Engineers: If you are a good Engineer, knowing your end Customer is crucial for you from the very beginning. You can invite Business Strategists to support facilitating the Vision for new markets, high-risk ideas or strategic movements – but you should not let it go it until somebody will define a backlog – because you won’t know the context of it. And this context is often a key to shape your architecture boundaries – and as a result, build a good code.
There are a lot of proven techniques which can help you defining the Customer and Vision for a new initiative:
- Business Model Canvas: a technique which will help you facilitate the workshop with your Business Experts to understand the Customer, Risks, Value Proposition, Market Segments and Channels – and also potential partners and revenue streams. It gives areas to ask questions and think on your company position on the market. It is a perfect tool to shape the Vision of Products and Services. It also can be used for shaping a vision for one particular product or service – especially if we are taking about online market of services and applications. More about Business Model Canvas you can find here: https://canvanizer.com/new/business-model-canvas. Business Model Canvas is a good technique if you have only the idea on your future market position and value proposition – but not on the Product itself.
- Lean Startup Canvas – my personal favorite, because it fits better for smaller initiatives (like building a single Product) than Business Model Canvas (which is better to shape a business strategy for the bigger organization). You can think about your Product Team as a small Lean Startup. The Canvas mostly focuses on the Customers – their potential problems or needs with the ideas on how to fulfill them; the potential advantage we might have over the competition, costs, revenue and distribution channels. More about Lean Startup Canvas you can find here: https://leanstack.com/lean-canvas
- Product Canvas – similar to Lean Startup Canvas, but directly implicating a Product as a center of interest. It may be useful for many scenarios, but I prefer the Lean Startup Canvas – because of more focus around the Customer, not around the solution itself. But when you cover Customer Part, you can always switch to Product Canvas (or use it later, for Catch the Essentials Phase). More about Product Canvas here: https://medium.com/qdivision/the-product-canvas-edf8df531
- Value Proposition Canvas – with a focus on Customer pains, gains and jobs within the whole business area/domain. I use this workshop more frequently to catch essentials of customer actions within selected product (you will read about it in next section, Catch Key Essentials), but it is designed to focus on our Customer needs within wider perspective. When I use it to clarify the Vision, I always ask additional questions on revenue streams, risks and potential distribution channels of our product or services. More about Value Proposition Canvas you can find here: https://www.strategyzer.com/canvas/value-proposition-canvas
![](https://khalasa.com/wp-content/uploads/2022/06/Lean-Startup-Canvas.jpg)
Of course discussing the vision and customers segments needs to involve business experts – but even if you are an Engineer, you can try to facilitate this discussion, supported with the frameworks I’ve mentioned. If you are talking about a wider aspect of your organization – where there will be more than one product or service mentioned – I suggest to hire a Business Consultant to help you understand priorities within Company Growth Strategy. But still, Engineers are a crucial part of those decisions.
#1: Result
You are going to have defined Customer, defined market environment, defined key value proposition and unique features, which you will know how to monetize and not bankrupt.
#2: Catch Key Essentials.
Ok – at this point you probably already know the Customer and have some vision on the Product you are going to provide. You probably have spent few hours on Business Model and Vision already – and you can’t wait to design the Solution Architecture and choose the Technology which will conquer the World… hold your horses! First we need to define features and priorities from our Customer point of view. We are again going to talk about the Customer, but we will now focus on the details – like: What our Customer does (within the specified area from Vision part)? What are the actions – current and future ones? What are the pains our Customer has? What is it that our Customer likes – about us, about our products, about our services, about the competitors solutions? What is annoying our customer in current solution (or similar to ours solutions on the market)? How can we solve the pains, how can we deliver the missing features – what will be those features? And most importantly – which ones are truly essential, and why? This is also a good moment to focus on our Team – and ask ourselves what do we need to have, what will we do, what are our pains and gains which will occur during designing, building and running the Product. It will help us to underline also the internal risks and potential organization issues.
![](https://khalasa.com/wp-content/uploads/2022/06/essentials-1024x447.png)
There are plenty of techniques, which can help to clarify the essentials and absolute priorities of our Product:
- Value Proposition Canvas – my personal favorite. It was described for a wider perspective on Customer Jobs and potential products & services in Define the Vision and the Customer part, but it can also be successfully used for catching the essentials – if we focus only on the jobs and features which Customer will do within our Product. During the exercise, we can ask our business experts (or selected Customers – why not!) on their pains and gains within their interaction with our Product (or similar products on the market) – and think together on how to boost the gains and relieve the pains. This is the place where a lot of ideas and brainstorming on features will take place. More about Value Proposition Canvas: https://www.strategyzer.com/canvas/value-proposition-canvas . Using Value Proposition Canvas, we can also focus on the Team – what the Team will need in order to deliver the Product (make it a separate board, next to a Customer).
- Mind-mapping – my second personal favorite. This technique is very open in its nature – we just put the word ‘Customer‘ in the middle, then ask the audience to write down every Customer need which they are thinking about (which can be fulfilled with our Product) as a first-level of the map. Then, for each need, we underline potential features and risks – and for each risk we put the possible remediations. For a mind-map we can also cover Team Perspective – this time on the same board as Customer, which will help us understand potential impact of features or risks on future performance and wellbeing of the Team. At the end of Mind-Mapping, you can try to group some areas of mind-map if they are connected or related to one group (or sometimes single) feature. Important remark: Mind-mapping is a technique to be used only with experience facilitators – it is easy to go far away from the actual topic with mind maps.
- Interviews & Questionnaires – it is a technique to gather missing functionalities and priorities directly from our Customers – but will be more time-consuming than the rest. This technique is about to make an interview or questionnaire with the Customer in order to understand the missing features, needs or potential reaction on the Product we are going to build. I personally like to enhance Value Proposition Canvas with such interviews if possible – because on VPC we don’t always have a chance to meet the end-user of our Products (the audience of VPC is often business experts and engineers – not always the users, because they might not exist yet if we are building a new Product).
![](https://khalasa.com/wp-content/uploads/2022/06/value-proposition-canvas.jpg)
Prioritize the ideas!
No matter which technique you will select to gather the requirements, needs, gain creators, pain relievers or features – the most important part of Catch the Essentials phase is prioritization. Without it, you will build the backlog for the whole Product, ending up with a year-long, tons of money-worth initiative, which will probably bring you nothing. We are focusing on the Minimum Valuable Product – so out of many ideas we need to now select only the ones truly essential. How to do it? Here are three useful techniques.
#1: Voting: You can ask your audience to vote on features or groups ideas. Allow everyone to use three-to-five votes, which the person can distribute to what they see as a priority. If you are not a fan of democracy (or you have a business expert or potential super-user, who will do the most of the value stream within the product or deliver you the biggest profit) – you can either ask only a group of participants to vote, or assign more votes to particular group. To be honest, I prefer equal voting – because from my experience, you will most probably end up with the same result, and nobody will feel less important on the workshop (or you can even loose business buy-in!).
#2: Comparison: You can take first two features, and ask your audience which one is more important. Let them discuss and provide at least 2:3 votes on one until you proceed. Once they select the winner – leave it with one hand, and take another, putting the “lost” feature on separate heap. Play this game until you have 3-5 priorities. Comparison is better than voting in terms of common agreement, but it takes much more time (producing similar results to voting).
#3: Interviews & Questionnaires: If you are conducting Value Proposition Canvas, Mind Mapping or any other technique with limited number of people – it is always good to ask more people or potential end-customers on your Product before you release it. You can underline the features you are going to deliver and make a market research with questionnaires and interviews with potential customers – allowing them to select the most important ones from their perspective. However, this technique has some limitations – first, you are going to tell your competitors what you are about to do. If they have better-shaped IT Organization, they might deliver it faster. Second – interviews takes time – so I suggest to implement on what you had voted and release it as fast as possible to gather the feedback on real product, not just a fuzzy description of features.
#2: Result
You are going to have prioritized features for your Customer (or Customer Segments). You are also going to have defined needs from your Team in order to deliver those features.
#3: Discuss on Details.
This is the moment where you know, who your Customers are – and what features are they expecting. Time to focus on specifics of those features – how they are going to work, what actions will your Customer take with your Product, what users are we going to have – and finally, how the processes within your Product will look like. We will also imagine and write down high-level Customer Journey within our new Application.
In this phase, you focus only on priorities selected on Catching the Essentials phase. You need to enhance features with processes, customer journey, interactions the Customer will have with your Product and events which those interactions will produce. You need to address the details of those events, orchestration, chronology, system users and potential edge cases. Yes, you are quite close to the System Requirements here! Within this phase, you need to think systematically and cover areas of your Product one by one (unlike you did in brainstorming during Vision and Essentials phases). You also need to be careful and remember about the priorities and the needs of our customers – so if the process you are designing here starts to be too long, you need to cut only what is necessary. And then repeat the exercise with cutting!
![](https://khalasa.com/wp-content/uploads/2022/06/details-1-1024x447.png)
Luckily, we have plenty of techniques which will support you with the Details collection:
- Event Storming – my current personal favorite. Much simpler than BPM or UML and easier to use with an audience which never played such workshops before. Event Storming is a technique which meets the language used by IT and Business – we can think about what happens (Domain Events), what leads to this happening (Command) and who is doing it (Actors). We can also put the details as Comments, we can clarify involved Systems or Policies. This allows Business Experts to imagine a flow of actions and results which our end Customer will perform – and IT people to shape system events, roles, permissions, users or integrations which needs to be implemented. Event Storming is a technique described on the official website: https://www.eventstorming.com and in the not-finished-yet book (but still worth to read, as it is already published. Think about it a little bit – real MVP in books industry!)
- BPM diagrams – my past-personal favorite, until I’ve started practicing Event Storming – yet worth to play with more advanced audience, familiar with BPM notation – as it provides both common language and detailed information about the processes and actors of the Product. BPM diagrams is a powerful tool, but sometimes can be too powerful – because the notation requires to have a complete picture of the process, which sometimes is not a good idea (or even not possible to create!) in the very early phase of detailing the Product. You can be smart though – and not fulfill all paths in BPM process, focusing only on most important happy paths, leaving a blank spaces for the rest. More about the notation here: https://www.bpmn.org
- Behavioral UML Diagrams – like Sequence Diagrams, Activity Diagrams, Use Case Diagrams. I also recommend to play it only with experienced audience, because it requires to have at least basic knowledge on the notation itself. Using the diagrams (I recommend to start with actors and main activities), you can shape the processes, users, systems and their events which will result in a complete flow of actions within your Product. The risk here is similar to BPM diagrams – remember, that at the beginning you don’t need to have a full picture – cover just the important flows and paths. More about UML you can find here: https://www.uml.org
![](https://khalasa.com/wp-content/uploads/2022/06/bpm-event-storming.jpg)
#3: Result
You should end up with defined Customer Journey and main actions and outcomes of it, which Customer will perform within your Product.
#4: Shape it!
This is the phase which most of Engineers will love – because finally, we are going to discuss Solution Architecture here! But not only – this is the phase where we will start with the backlog skeleton, prototype Customer interactions with the Product and initiate the Team formation. Within this phase, we will design mockups for frontends – and whole Customer Journey for MVP release. We will work on the architecture to fit MVP scope, flexible enough to develop the product after first release (it will be possible to design for Architects now, because they already know the business case, details and ideas from Business Experts from previous phases of modeling MVP backlog).
![](https://khalasa.com/wp-content/uploads/2022/06/shape-1-1024x442.png)
Unlike with the previous phases, where I’ve putted here some techniques to choose – now I strongly recommend to play all of those below.
- User Story Mapping – a technique to initiate the backlog creation, where out of Event Storming (or BPM/UML – but it will be more difficult) we take the Aggregates, Events, Commands and Actors – and form them to detailed Epics and User Stories. In short – most of Aggregates and some Events will became Epics, and most of the Commands (decomposed to simpler actions) will became User Stories. In other words, User Story Mapping is a technique which will decompose the Processes from detailing phase, and put them into Stories on which the Team will work on in Sprints. It is important though to shape the stories from the Customer (Business) perspective – a good story starts with “As an Actor, I want to do some action”. The worst possible User Story tells the Team what to do – like “Implement Customer Service” – instead of telling what to achieve. Within User Story Mapping, there are also two things to align with the Team. First is Definition of Done – a checklist from Product Owner to the Team defining what Product Owner considers as a finished Story (like Story functionality is deployed to Production). The Definition of Ready is a checklist from the Team to Product Owner – what needs to be defined in a Story, so the Team can estimate it and take over (like Story needs to have why statement). That is why I have mentioned the Team formation within Shape it! phase: there is a mutual commitment from the Team and from the Product Owner. If you are interested more in User Story Mapping in practice, I recommend the book: User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton.
- UX Prototyping – this is a technique which will require minimum skills of writing mockups in the whiteboard. Don’t worry, those mockups does not need to be beautiful – it is not a final vision of what the Customer will see, just a skeleton of how the end user will interact with our Product. UX Prototyping can play a support role for our User Story Mapping – I am often using it as a first technique after process design (using Event Storming, BPM or UML) – so the audience will imagine the user experience and shape the stories from particular actor perspective. It is worth to invite some UX Designer for this part of workshop – but I would not consider it as a must.
- Solution Architecture Design with Structural UML – this part I often play at the end of User Story Mapping, asking Architects and Developers to think about first draft of the solution architecture. Why I do it during a workshop with Business Experts? Because at this moment a lot of additional questions and possible technology limitations are reaching the top. It is also a moment where Business Experts and Product Owner will have at least basic impression of the future solution design from technical perspective – allowing them to understand how the Product will be built and why. I recommend to use Component Diagrams, and some Sequence Diagrams for more complicated stories – the architecture can change during the final backlog formation or later in the sprints, but my experience says that at least 80% of first design will stay the same (which also have some proof to be correct for most of the cases in Pareto Rule).
![](https://khalasa.com/wp-content/uploads/2022/06/user-story-mapping.jpg)
#4: Result
You should end up with backlog draft, defined to User Story level, solution architecture and some skeletons of UX mockups.
#5: Form the Backlog and start with delivery.
This part I sometimes as a part of daily work with Product Owner (and Delivery Team, if possible) after the first four steps – because for each User Story, Product Owner needs to think about Acceptance Criteria, put some details of what is important within the Story from Customer perspective – and create a Why? statements in User Stories which will help Product Owner manage the backlog weeks (or sometimes months!) after the initiation. It is a time consuming work – so not every Story needs to be filled with Acceptance Criteria or details from the very beginning – but we should focus on the crucial and the ones which will be taken to be delivered within first Sprint or Increment (depending on the agreed approach – I recommend Scrum for Products).
For facilitators: Lay the backlog to Product Owner hands!
If you are only facilitating the backlog creation – but you are not the Product Owner – you should step backward now. Let the Product Owner finish the backlog – because it needs to have Product Owner vision on details of the User Stories. It also requires Product Owner prioritization and acceptance criteria. This is a time to establish the Ownership.
If you are working with inexperienced Product Owner – make a “pair-backlogging session” to support the person within new role. You should also encourage this person to have a full power over the backlog – not to be afraid to add or remove something.
![](https://khalasa.com/wp-content/uploads/2022/06/backlog-1024x442.png)
Once the Acceptance Criteria and details on the Story are ready – according to agreed in Shape it! definition of ready, I recommend to do the first refinement with the Team – where developers, testers, devopses and other team members can decompose a story to understandable tasks (from many perspectives – both technical, business and organizational areas). If you do it – you are ready for first Delivery Sprint Planning (or Increment Planning)!
This exercise needs to be repeated during Minimum Valuable Product delivery – because some stories will probably change if Product Owner and the Team have more experience and feeling of the Product. It is important to remember that Minimum Valuable Product is only the beginning of the journey – with MVP you are going to prove the concept and gather Customer feedback, on which you need to reply with the next release. And the next release. And the next release… until you decide to roll-over the Product (after making a bunch of money and buying an island somewhere, where the weather is warm and pleasant – for your retirement… ahh!).
![](https://khalasa.com/wp-content/uploads/2022/06/backlog-ready-1.jpg)
#5: Result
You should end up with the backlog with details, on which essential stories (and the ones for first iteration of delivery) are fulfilling Definition of Ready – and can be taken over by the Delivery Team.
Conclusion and some hints
Forming a Minimum Valuable Product backlog is much more difficult than defining the whole shape of the Product, with every functionality described. Why? Because you need to focus only on what is essential to make the Product successful – and it requires more detailed knowledge about the Customer and situation on the market. But it is worth to invest in it – because while your potential competition will be spending three months on defining each step of each process and each edge case of their Product – you will already be on Production and gather real feedback from your Customers. And you will be first. And you are going to make money instead spending it on analysis. Sounds cool, right?
There are some hints at the end of this too long (again…) blog post. First – have an open mind, because Customer Feedback may surprise you. It may appear that the aspects of the Product which you analyzed the less will bring you biggest profit. Or – Customers will love your product so much, that they will expect more features sooner than you expected (meaning you need to scale). Or maybe the Customer you have imagined actually exists in the market segment which you have not foreseen. Anyway – be ready to be flexible. Be ready to make mistakes. Be ready to adjust – because this iterative, MVP approach gives this possibility to you. Also – think of Software as an Investment, not a fix-priced cost – because you don’t know what will happen and what scope will your product has after the MVP phase.
You need to focus on your mindset and approach while even starting with MVP. This is a great video, which I hope will help you with it:
If you need any help in facilitating such backlog formation (trust me, experienced facilitator is equally important as an idea itself) – or you have the idea, but you miss the Team – contact me. We will together find the Minimum Valuable Approach!
Everything is very open with a really clear clarification of
the issues. It was definitely informative. Your website is useful.
Thank you for sharing!