Define your process for building better products
Whether we build something from scratch or we keep adding to existing products, there’s a lot to consider. As the saying goes, we “eat the elephant — one bite at a time”. But how does that work, exactly? Surely some processes are more efficient, inclusive and repeatable than other.
If we were to think of this process we follow on a maturity scale, on the lowest level, it’s a gut feeling of following your nose and get something that you think users want, and build out new features until you’re done — or you think you’re done. As we rise on a maturity scale we start creating a repeatable process that scales beyond ourselves and becomes the way-to-work for our team and it’s shaped by our team to formalise a repeatable process that’s not reliant on a specific person to get things done. It draws from the strength of all roles in the team and amplifies the output that we can achieve together as a team.
The second key thing we need to keep in mind is at the end of the day, we’re building something for our users. Without them there would be no product. That’s why I’m a firm believer in a user-centric way of designing and delivering products, it’s all about them and how they can easily interact with and use our product to form part of their lives.
I’ve typically worked in an agency environment with client projects ranging from all sizes. The past couple of years, I’ve scaled down on client work, and solely started focussing on product work. I’ve worked on teams of various sizes, and really trying to hone in on a process that fits the smaller to medium teams that I tend to work on. In the past, it was difficult fitting an agency's workflow with projects of all shapes and sizes into an agile process, and I kind of reserved this for pure software delivery projects. Lately, I have been working more and more in the typical “software building” teams where the team is focussed on building out features for a specific set of products. Naturally, I reopened that “tab” in my mind to revisit the agile way of building products, and there are some key building blocks that we can make part of our vocabulary and process to make things easier and get everyone on board. It does not have to be intimidating, and the concepts are really simple, yet fundamental to getting a repeatable process that anyone on the team could follow.
The number one measurement of success for agile is having functional software that has shipped to production. It’s not really about all the other mundane tasks we need to get this done, although those are the shared language with our team to get everyone pulling in the same direction. We need to commit to a functional process that makes the whole team (or squad) responsible for delivering against the agreed upon scope, so that we can make an impact in our user’s lives.
Scrum
Scrum is an agile process you’ll hear of a lot. It’s a process I ignored for a long time as I’ve typically coordinated work in smaller teams, and this felt like a way to organise larger teams. So, in fact, I don’t care about Scrum… what I do care about is what it unlocks. The building blocks that it’s made up of and the shared vocabulary that we can use to work towards the same goal. At the end of the day Scrum is a framework that unlocks so much potential and speeds things up, and that’s what I’m attracted to.
The Scrum framework is built on three pillars that allow empirical process control:
- Transparency: you gather data — like metrics, feedback, and other experiences — to find out what is going on,
- Inspection: you inspect the progress with everyone involved and decide what that means for your ambitions,
- Adaptation: you make changes that you hope will bring you closer to your ambitions,
This cycle repeats as often as necessary to catch deviations, unexpected discoveries, and potential opportunities that emerge as the work is done.
It happens not once a year or when the project is completed, but continuously on a daily, weekly, or monthly basis. Rather than making decisions based on assumptions about potential futures, you’re making decisions on the data you’ve collected up to this point, based on evidence you can actually see. This is empiricism.
So when it comes to deciding on what to build next, how do we document and handle that process?
Collect your ideas
Generally we all start with an idea of what we want to build. It’s either some gap we’ve spotted, a need expressed form a user or our gut feeling we want to test out. Either way we start with a bigger picture in mind of what we want to build. Mature teams have come to understand that it’s okay to collect these ideas in a list (or product backlog), and it’s inevitable to have a long and continuously growing list.
Epics
Sticking to Agile terminology, some ideas might be Epics. That’s just a name for a larger idea or initiative that you can group a bunch of tasks under. An epic is not something that can be actioned, it’s high-level and simply explains the concept more than what to actually do to start solving it.
Break down ideas into user stories.
Coming from a technical background it’s easy to jump onto that bandwagon and start thinking of what’s needed from a technical (front-end, backend, database, etc) perspective rather than thinking of what the user actually wants. We need to think of the “vertical-slice” of what that whole user story should be comprised of — without being technical. We should be able to look back at the end, with this one story complete, and able to run through it and test it in totality.
Sort and Prioritise
Generally when planning your next sprint or time block of work, you spend time to sort and prioritise the ideas into the features that would bring the most value to your users. If we break down our stories as explained above, we would have a list on non-dependant stories. When stories are too dependant upon each other, it’s not a good thing as it makes prioritising and sorting them a lot more difficult. At this point we would want to start adding more details and adding tasks to our stories.
Expand on your ideas
Expanding on your ideas is done in a “just-in-time”-manner. In the illustration I tried to show conceptually what a workflow could look like, these are not cast in stone, but generally you start off with ideas (or Epics) on the far left side of things to do later, as you’ve prioritized and they become items that you want to work on “soon” or “next”, that’s the time to start defining them more. There is no use in having detailed conversation around ideas that you’re not working on in the near future. All that detail might go lost, or most certainly will change by the time you get to it later in the process.
When the time comes to break things down, we typically write user stories as mentioned above. User stories, are exactly that, it expresses, in plain language something that a user would want out of the product. It typically follows the template of:
As a [Type of User], I want to [Needs], so that I [outcome].
Why create user stories?
User stories serve a number of key benefits:
- Stories keep the focus on the user. A To Do list keeps the team focused on tasks that need checked off, but a collection of stories keeps the team focused on solving problems for real users. Remember that “vertical-slice” of a complete feature, that’s what we’re after.
- Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
- Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal.
- Stories create momentum. With each passing story the development team enjoys a small challenges and a small win, driving momentum.
How to write user stories
In addition to the single sentence user story, consider framing the following when writing user stories:
Definition of “Done” (also called “Acceptance Criteria”) — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.
User personas — For Whom? If there are multiple end users, consider making multiple stories.
Ordered Steps — Write a story for each step in a larger process.
Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
Time — Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own “epic”.
At the end of the day it’s about managing risk
Teams are often worried about the reduced business value of smaller items. Of course, smaller items will have reduced business value compared to the larger item. But the primary purpose of breaking down functionality is to reduce risk, the smaller the scope of work, the more accurate you can estimate on how long it will take to deliver and the easier it is to deliver and test out that “slice” of functionality. The aim is to increase flow and increase the amount of working functionality that can be reviewed at the end of every sprint.
Squads
So far we haven’t touched much on the team composition and perhaps I’ll leave detailed opinions of that for another post, but generally we work in squads. Typically a squad has at least 2 developers, a Product Manager and product designer (for user facing products). There are almost endless possibilities when it comes to aligning different squads to features, customer personals or various stages of the product-lifecycle. From my perspective I’ve worked mostly on smaller squads where we’re responsible for everything, so prioritising becomes key! Find out more about Squads from the InVision documentary.
Who writes these stories?
Most teams would have a PM (Product Manager) or PO (Product Owner in Agile) who does this feature defining work. If you don’t it should ideally be someone else that’s aware of the whole feature-lifecycle as well as the product vision and roadmap to know what’s coming down the pike and fits into the overall strategy. With that said, it’s not solely a PM who can create stories. Anyone can identify a need, create a story and add it to the backlog. There would just be a single person (PM, PO) who is responsible for the backlog, prioritising that and driving what the business objectives are for what to build next. When stories get closer to the top of the backlog we’ll exercise “just-in-time”-definition where the PM/PO would dig deeper into the actual task and define that in accordance to the criteria set out for a single user story.
Sprints or Iterations
“Sprint” is a terms that has received some negative connotations in the industry linked to burnout. No one can “sprint” all the time. Another term a squad could use is “Iterations”. Generally, the idea is taking the top priority items from your backlog and bring that over to your “Sprint backlog” — some teams do this by assigning effort to stories, and have a maximum number of effort “points” that could fill a sprint, this makes it a repeatable process that helps planning ahead. If you’re just starting out, I would advise to just get started, not to worry about the points, and just record what you get done in your sprint. Sprints can range anything from 1 week to 3 weeks. The key thing is to keep it consistent which would help in producing similar results.
Key takeaways
- It should be a repeatable process.
- It should not be reliant on a specific person.
- It should draw from the strength of all team members, encouraging collaboration.
- We’re creating products for users, they (and their needs) need to be at the centre of how we think through new features and stories.
- Our primary objective should be to deliver shipped functional products that makes an impact in our user’s lives.
- Define user stories with a definition-of-done to capture a non-technical “vertical-slice” that we can look back at to be able to run through it and test it in totality.
At the end of the day everyone has the same objective, to ship usable code to their users. Your approach can make the world of difference on the quality that you can achieve, and if you can manage to tap into your team’s full potential.
I don’t think there is the right number of steps to follow, and a lot of the time it’s what works for the team. If you go into more detail in the Agile workflow there’s more that you can add, and if you’re a smaller team, there’s some you can take away. It’s all about experimentation and finding what works for you. If you consider the key takeaways above to shape a process that works for your team I don’t think you could be too far off from creating something very efficient, reliable, and scalable.
Have you done some things different and achieved great results, let me know in the comments below.
Keep up to date in real-time by following me on Twitter where I tweet all about building great products from a design, development, product management and strategy perspective.
