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.

#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?

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

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.

#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.

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).

#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!

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

#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).

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).

#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).

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!).

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!