This is our playbook for Connected Home. It is a good set of guidelines for how we operate, interact and develop amazing products in the Internet of Things space.
It is filled with our learnings from this company, many other companies & startups of varying sizes, but please know this is a changing document meant to adapt as we learn & adapt.
Everything here is a suggestion, not a rule. It is to help if you are not sure about how to achieve something or what to do, it is not a strict guide.
We are a Centrica-owned, data company serving both individual people as well as large corporations.
We prefer guides, not hard & fast rules and processes.
Processes and strictly defined rules increase complexity & overhead, they also seem to stifle creativity and the freedom of people to develop new ideas. So we like guides. The most important ethos here, “use your best judgment”.
You’re smart, you care about your work, your colleagues and the business; keep all this in mind when making decisions and taking action.
We work in a lean way employing lean principles. We use the build, measure, learn cycles with nearly everything we do, but in order for this to work we need to think about minimum effort & minimum resources.
We want that Lean Loop to be as short and fast as it can be to give us the information we need. This means making sure we efficiently use our time in each stage of the loop to do only want we need to do.
Ok, so this is partly an attention grabber since you never hear a company claim to be or even promote people to be lazy. However, it is a good way to think about work.
We not only want to be fast, but also to put in the minimum amount of time & effort. Do just what you have to do to get the job done.
Don’t build a native app when an Invision prototype will do.
Don’t build an Invision prototype when a paper prototype or sketches will do.
Get your ideas out there fast and learn from them.
We regularly reflect on how things have gone and identify tweaks we can make to be more effective at both a team and a personal level.
We want results, not processes – we want outcomes.
Whether it's finding customer pain points through an interview with a user or validating an idea using A/B testing in a live product; we want to work towards outcomes, not towards creating assets, libraries, slide decks or more processes.
Automate everything. E-V-E-R-Y-T-H-I-N-G.
This is not just for development or testing; there are processes we all do over and over again, and if we ever repeat ourselves we can find a way to automate the process.
Look at tools such as Zapier and IFTTT to help make your processes more streamlined and to help you do less work.
Regarding automation when writing code and running tests, we will deal with that in our tech/ programming section.
We don’t like hierarchy any more than we like processes. We also don’t like silos of work nor silos of people.
When too many private conversations take place about the products we are developing things get confusing fast. Keep conversations open and make sure to document any outcomes for the rest of the team.
Closed conversations happen; Mary bumps into Susan in the stairwell and they make a decision on something. Susan then has a conversation with Jack about that same thing, but Jack had a conversation with Mary earlier about it with a different outcome! This makes everyone confused!
If you have a conversation, and it is not open & digital (ie: in a public Slack channel) and it affects the team or the product, document the outcome somewhere. Don’t write out the whole thing, but make sure the outcome, the decision made in the conversation, has been documented for everyone to see.
We don’t have managers, we have coaches. (OK, we do, but think of them as coaches.)
We don’t have a lot of hierarchy but we do have directors & managers. Directors are there to provide a service for the managers. Managers help to create the playground for the smart, talented, engaged people we have here.
Some people were hired for certain functions and have experience and expertise in those functions. Some are even authorities in those functions/ areas, but we don’t like anyone dictating to anyone else.
We help each other learn & grow, we teach each other what we know and we always look to learn from our colleagues. We are all one team.
Always optimise for shipping the fastest, smallest, simplest thing that will get us closer to our objective and help us learn what works.
Scope projects into small, independent releases which add value to customers.
Everyone should push everyone else to reduce scope and simplify, in order to move faster and not spend time on things that turn out not to be important.
Teams have weekly goals, broken down into daily and sub-daily goals.
Every individual should know at the start of the day what their goals are for that day, how they relate to the team’s weekly goal, and to what is being released.
Always fight anything beyond a lightweight process, and use the minimum number of software tools to get the job done. Always.
Don’t just charge off without thinking about what you’re doing. Spend the time needed to formulate a plan, but know that nothing ever goes fully to plan. It simply provides the direction for the first couple of steps forward.
Take the steps, look around, absorb and react to new information; use this to adapt and continue moving towards the desired outcome.
Always remember the team are there to bounce ideas off, or book a planning meeting with relevant people to come to the solution as quick as possible.
This should be very straightforward, but when you stop to think, we have a lot of different tools, channels at our fingertips to communicate with people synchronously & asynchronously both in-person and remotely.
We are too small a company, with too many things to achieve, to worry about politics. All communication should be 100% honest and backed off with how you feel. We communicate in open channels, not in closed, siloed ones. Sure there are times when you need to have a private conversation someone about a private issue, but when you discuss a project, the product or anything to do with the wider team, make sure it is open & honest. If it is something you feel you can’t discuss openly then document the outcome somewhere everyone can access it.
We use clear language. We say it straight and we make what we say accessible to everyone.
We try to keep jargon, abbreviations and acronyms to a minimum. Sure, they help us communicate faster with those team members ‘in-the-know’, but think about other members of the company outside our small teams & groups, think about new members and having to get them up to speed not only on the work but on the jargon. Real language. Real clear.
Ask if you don’t understand something; don’t be embarrassed to do this - we’ve employed the best experts in a wide variety of fields so nobody knows everything.
We are a digital company, we have digital tools, these are what we use to communicate.
Try not to print. Not only will it save paper, but when you do print that asset is locked in time and space. We want to be able to edit, track and collaborate on our assets, so keep them digital. This means everyone is on the same version and we have versions (we can go back and see changes when needed if it gives us a clearer picture of the story).
Digital communication also helps us with documenting/ noting outcomes of conversations. If you have a conversation in a digital space such as Slack, then it is already documented. However, if you are having a phone or a face to face conversation then as we already talked about in Open & honest, document that outcome for everyone in a digital space.
Embrace the cloud. We use collaborative tools wherever possible, like Google Docs, Slack, JIRA, Confluence, Hack Pad - the list goes on and on! You will find a full list of our tooling in the ‘Tools’ section of this document.
We are collaborative, not just co-ordinated. There is no exclusion by function here. Everyone can be involved in or have access to everything. This not only helps give everyone a clear picture of the different pieces of work going on, but it means we draw on a larger pool of experience and knowledge.
We all have function to serve, but we all are working towards the same goal and have things we can contribute to that work.
You don’t have to ask permission to take responsibility, but you must provide clarity of it if you do.
So go ahead & do something, take ownership of your work, make a call and make a change, just make sure to let everyone know what, how & why you just did something.
If there’s one thing we as an organisation are still learning to cope with, it’s criticism. Of course we know that constructive criticism brings to the fore the things that we can improve on in our own working environment and we know that when we act on the feedback given, it gives us the opportunity to continuously improve and to be more responsive to issue as they come up - this is our culture and everyone has a say in making it better for the long term.
Every Friday, when you leave the office for the weekend (or, on your last day in the office for the week), put an emoticon and some feedback on a Post-it note and stick it on the ‘happy door’ as marked by the sign, when you walk between the work space and the kitchen on the first floor (your name is optional - if you want an individual response, put it on there).
You should not leave without telling us how you feel overall (the emoticon) and without giving feedback on at least one thing about the week. This can be something you liked, hated, want improved or even that you are unsure about.
We are trying to build a listening organisation, this is one way we get to find out how to make things better if it’s possible to do so!
Happiness at work matters. We know from experience that when we achieve greater levels of happiness at work, it has a huge impact on the productivity of ourselves and our colleagues. So, inspired by books like ‘Drive’ and ‘The Carrot Principle’, we wanted to give people the opportunity to ‘flag up colleagues we think deserve a bit of extra recognition’ - we have started using the ‘Kudo Box’ principle as a way to do exactly that.
It’s a simple idea: we have placed a golden box and a stack of ‘kudo’ cards on the window ledge in the first floor kitchen - if you feel that a colleague has done something great and you want to recognise them for it, you fill out a kudo card (with your name, their name and the reason for the kudos) and put it in the box. It’s a public thing and everyone gets to see who complimented who and why when the cards are presented at the bi-weekly show and tell. This is our way of making sure we step back and look at the work we all do, and highlight all the good stuff.
People work differently within teams and sometimes not all working environments are ideally designed to get the best out of people. Within the Delivery Team we understand this, so on a regular basis we will review the Ways of Working within the team. This could be triggered due to changes in what the team are delivering, changes in resources, changes to external teams, general review etc.
Ways of Working is a set of rules that we are a Delivery Team will abide by and covers everything that interacts with our working life, for example, how we work with Product, how UX designs are based over to the Delivery Team, how the boards and processes work, the list is endless but it is good for everyone within the Delivery Team to feed into the Ways of Working to ensure that working life is fun and optimised for delivery.
Ultimately we are measured on our delivery and not how often we sit on our seat. It is essential that we remain as a team and continue to work closely together, this will help us deliver to our timeframes and make sure we continue to hold ourselves to account on work we do.
Saying that, there are times in all our lives where working from home is needed for the odd day, be it a doctor appointments, picking up the kids, helping family members etc. If there are circumstances where you do need to work from home, on the odd day, then please speak to your line manager and your team to ensure it is OK, remember to give plenty of notice so team members can organise anything they needed to do with you.
We all need to take holidays, holidays let us relax, recharge our batteries and spend some time focussed on us also sometimes we deserve it. Holidays in Connected Home is simple; speak with your team and Line Manager to ensure there are no major releases coming up and book it into the team calendars.
Everything we do we own. The Product Owner may prioritise the work that is on the boards that we pull tasks from but we are the owners of delivery and we should be making sure we hold each other to account, including the Product Owner. If there is a task on the board that does not meet our Definition of Ready then it should not be there and we should be asking the Product Owner to clarify why they have put it on the board, there might be a valid reason that we are unsure about.
When it comes to the work items on the board we are completely responsible for the work items that we pull through the board and in what order, based on the priority of the theme, epic or story. We are also accountable for our cycle time so we should be owning the process on the boards and also supporting our teammates to get stories through the process as quick as possible. Remember just because you might be a developer does not stop you from testing other people’s work, building an environment or releasing code into Production. The only silos in the ME teams are the ones we put there, and we are the only ones that can remove them.
The development team should always make sure they are pulling work items through the board and updating them as they change status. The board is a primary communication mechanism to the business and should be updated daily, can be hourly if the team are moving quickly. If the board is not up to date then as a delivery team we are going to have stakeholders and other people come and ask for updates so it is in our best interest to update it.
We are flat hierarchy, each of us is responsible for what we achieve and how we do it. Some of the team are accountable for the decisions around the delivery and also what functionality needs to be build but this should not stop decisions being made within the delivery team.
To support decision making in the team we hold regular Delegation Mapping sessions that are used to clarify the expectation and delegation level between the owner of the decision and the team.
These session are run on an Ad-Hoc basis, decided by the team. Each team member has 7 cards, these are:
At the start of the session the team spend 5-10 minutes to write down all the decision activities, on post its, that are part of the their work lives, this could be from holidays or seating plans to what software languages or hosting environment should use.
Once these activities have been documented they are put onto a wall and discussed with the owner and the team with both agreeing on a score from 1 to 7, based on the cards above.
We should look at reviewing the delegation map every 6-8 weeks, or if a significant event has happened with the team. Review sessions can be requested Ad-Hoc during a retrospective review as well.
To deliver efficiently we use Kanban within the My Energy Team and My Energy Live Team. This process gives control to the team so that we can pull through items that are aligned to the objectives of the Product Team as well as giving the Product Team flexibility to change their mind on stories in the backlog. We allow our Product Team to change any epics on the board that is currently not in progress.
Cycle time is the amount of time a work item spends as work in progress. The measurement starts at the commitment point which is when we move an item from ‘Todo/Next’ state to ‘In Progress’ state and ends when the item enters ‘Done’.
We as a team focus on Cycle Time as the more efficient we are the more items will flow through the board and ultimately the more work we deliver BUT speed should never take priority over quality and we must keep to our values.
Like most Agile houses we have whiteboards that show the work items that we still need to do. There are two whiteboards used within the My Energy Programme one for each team and they are owned by the team. The delivery team specify how they want to work (see ways of working later) and these are implemented as states on the board the team then pull the work items through the states from left to right.
The Product Owner changes the items on the board to ensure work is prioritised and there is enough work for the team. This could be at any level, it could be stories, bugs, epics, themes etc.
Work in Progress limits are essential to ensure we are getting a flow of work through our process. Without WIP limits the board is a simple to do list and it becomes difficult to identify bottlenecks within our process.
There is no science behind setting WIP limits, within My Energy Programme we simply count up the resources within the team in each discipline for a particular status and then multiple that number by 1.5. For example if you have 3 devs you could have a WIP Limit of 4 or 5 for the In Dev column.
WIP Limits should be constantly reviewed as bottlenecks are bad for flow and you could end up with resources doing nothing which again is not a good thing.
The team are responsible for the limits and can request them to be changed but it is important that the limits are changed for the right reason, i.e. we are trying to increase flow capacity rather than we just want the developers to be more busy.
When it comes to planning the team need to be transparent to the business so that they can self-organise around work that is deemed important to the business. Sadly not all work items have the same time pressure or level of value causing some work items to be treated more urgently or being required to be delivered faster than normal to enable the business to realise business value earlier than expected, this is where class of services come into play.
Class of Service allows teams to create policies around work items, this could be an expedite service, a fixed delivery date service, regular service etc. Each service will carry their own policies that define how the service is implemented, for example expedite service could require us to:
Each team has a Definition of Done that is documented during a Ways of Working session. Our Definition of Done is used to set expectations within our team and stakeholders about what we agree is ‘Done’, an example of this:
These statements are completely controlled and agreed by the team and are regularly reviewed as our environment is constantly changing, for example we may have 5 million customers and Releasing to Production might have to happen on a monthly cycle (ugly!) or Apple’s app submission approval process may be taking longer an usual so we might want to not release apple products as part of the Definition of Done (ugly!), hey anything is possible.
Daily stand-up meetings have become a common ritual of many agile teams and ours are no exception. We know from experience that meetings that take too long tend to have low energy and participants not directly related to a long discussion will tend to be distracted; when we get together as a WHOLE team each morning we ‘walk the wall’.
We do this in order to:
It's really easy for people to get more focused on being busy rather than actually progressing the work; to focus the team we have switched to a model where Work Items 'attend' rather than people and we 'Walk the Wall', that is, we structure the stand-up by walking through each work item that is displayed on the kanban board. The stand-up moves through each work item from the end of process to the start of process (i.e., right-to-left) and from highest-to-lowest priority (e.g., top-to-bottom).
Our default sequence:
During the process of walking the wall we take the opportunity to add a very simple visual indicator to the cards once discussed - a 'dot' is added to the face of the card to indicate another day on the cards cycle time; it helps in the conversation and focuses the team on the all important Cycle Time.
We know that using the Walk the Board method has a much greater tendency to succumb to the ‘Reporting to the Leader’ anti-pattern and for that reason, we use the ‘rotate the facilitator’ as pattern for self-organisation.
Teams meet where the work happens, not in a meeting room - the workplace has many memory triggers which helps members recall more details about what is going on. We also want interested parties to be able to drop by to observe a stand-up to avoid having to schedule yet another status meeting - for these reasons, teams always meet at the same time and place for a maximum of 15 minutes. Many of the teams have a “Kanban board” and will meet in front of that.
We are a digital company, we use digital tools. Here is a rough (by no means exhaustive) list of the tools we use day to day:
and they each serve a function...
Communication. Conversations. A central point for finding people to start a conversation. these can be both synchronous & asynchronous. However, if a decision has been made, document it somewhere more permanent. The search feature in Slack is great for going back to find a past conversation, but it is not the place to document outcomes.
It is also great central springboard. Make use of the integrations and create new channels to focus them. Thing such as Github, Invision, Trello and Wordpress; we have channels set up which listen for changes and will post notifications if projects change. This is handy to keep you from having to look around a large number of websites, just focus on Slack and get notified of anything new.
Design discussions, showcasing & prototyping. Invision allows you to have a design discussion over time & space as well as a real-time discussion with a distributed team, all looking at the same asset.
It also allows the ability to show design work fast with it’s Sketch integrations, and to create quick prototypes, along with many other features.
When working with development teams it helps collect & organise the assets they will need to code the designs.
This is our defacto design, wireframing and with Invision, prototyping tool. It is simple to use, vector-based, well-supported and compared to most other offerings, cheap.
This is great for us to design more detailed vector assets should we need them. It is useful for designing icons and logos with more control, which in turn we can use in an SVG format with our Sketch app files.
Great tool for us to use for creating mockups when working with bitmap images.
This is where we can create & tell stories around our work, things we find learn, create or find interesting which we think others will find interesting. We can create a short or a long blogpost about it to give it a bit more life & context beyond a daily stand up or a Trello card. We can also have a private, invite only version if it is things we do not want to share with the public.
This is one of our documentation tools. It forces simplicity with its limited styling features. It is a central place for us to document processes, outcomes or projects.
Documentation. Collaboration on documentation. Presentations. Or anything else that is too long for Slack which we do not want to get lost. Sometimes you need a spreadsheet or a powerpoint deck, then this is where Google docs comes in.
These tools are not well-suited for large documents or complicated spreadsheets, which is great.
We are biased toward minimal documentation and upfront specs so we shouldn't be writing long documents.
For cases where we are writing large spreadsheets, we find it's faster to snap together a small app to do the job. This is a good time to ask if such complicated analysis is really necessary.
We like to be collocated but with the tools available to us it is hardly even necessary nowadays, but since we do believe in open communication and face to face is better than voice, this is where video calls come in, and Google Hangouts are the easiest to setup and use since all you need is a browser. You can even do it from a Slack conversation.
Skype is also a good option, but if not everyone has it installed or has the relevant people as a contact, keep it simple and use a Google Hangout.
As mentioned earlier along with IFTTT, Zapier is a great tool for helping out with automation and allowing you to build the equivalent of a basic app without having to code.
This is our version control for our code we write.
When we need to meet for a discussion, we aim for 30 minutes spent in-person. This does not include workshops such as JTBD, Design Studios or Design Sprints.
We also all have the power to push back on & refuse a meeting.
Feel the purpose is too vague?
Ask for clarification.
No defined outcome?
Ask for that, too.
Feel the meeting is not relevant or you have other things to focus on?
When working remotely, Google Hangouts are indispensable as the "next best thing". They are easy to set up, sharable by URL, and let us get a look at whoever we're talking to.
We work a sustainable pace.
If there is a company holiday during the week, or if a team member is sick or unexpectedly absent from client work, we'll use Friday as an extra client day to avoid slipping behind schedule.
When taking a planned vacation or attending a conference spanning multiple days, we generally don't "make up" client work on investment days.
When taking time off during client work, we discuss how it will impact the schedule with other team members.
Sending off-hours communication may create an unintended sense of urgency with the recipients of your message. Try to avoid creating that urgency when possible.
Unless actually urgent, you may ignore off-hours messages which you receive and handle them once you are back at work.
We are a Product company and most definitely not a Project company.
Although products are often born at the point where a project ends, unlike projects, products are living things and should be treated as such. As a product company, we know that real learning, in terms of the success of our solution, in solving customers problems, begins when we bring a product to market. We recognise our customers are committed to a relationship, not completing a one-time transaction.
One of the trickier things about being a product company is the rest of the organisation often doesn’t understand all the Agile ways of working and jargon which surrounds our product teams – “it’s like they’re speaking a different language!” But the product team needs to work with the rest of the organisation to make the product happen, so it’s important that everyone at least understands why we’re working in this particular way.
What we need is an introduction to the ‘why’ of being a product company: the common-sense principles which make it clear why this product, and not project way of working, is beneficial.
These same principles also happen to underpin other approaches we are using such as human-centred design, Lean Development and the Agile methodologies. We certainly find ourselves ‘standing on the shoulders of giants’ here – there is no need for us to reinvent the wheel.
Here are our seven simple product rules which inform everything we do as a product company:
When thinking about the core user's experience of our product, it’s common to think in terms of a simple, beautiful, and easy to use feature-set that makes the user’s life easier. The reality is that features are only a small thinkable set of solutions to a user’s defined problems. It’s all too easy to get bogged down in developing features but It’s not the features that are important, they should be secondary to the reason a customer or user uses our product. Product Thinking advocates starting with the specific user’s problems in terms of a set of ‘jobs to be done’, it ties in the user's goals and objectives while still considering the wider end to end of the product lifecycle.
“The core user experience is not a set of features; in fact, it is the job users hire the product for…. There is a one-way interrelationship between feature and product: Features don’t work without the product. This is why we should think in terms of products first.”
Product thinking enables designers and product managers to build better products. It’s a way of examining every product design decision in the context of the problem the user wants to solve. It makes sure we tackle real user problems and herewith reduce the risk of building something nobody wants. It gives the power to make the right decisions whenever it comes to building features. It also extend the relationship between UX and product management.
The first step of product thinking is to find the problem our users are looking to solve. As long as our product actually solves the problem in a meaningful and valuable way, they are likely to use it.
If the problem we choose doesn’t actually exist, it isn’t significantly painful, or the solution we propose doesn’t actually solve the problem – our products are going to be worthless to users.
Sure, there’s the possibility that if you get the solution wrong – we can fix it but if we solve a problem that doesn’t exist; there’s little we can do about that in the post-launch analysis.
Finding real problems is difficult sometimes. Even when we do lots of upfront research, it’s still possible that we will identify a problem that doesn’t exist. However, we know from experience that the right place to start is always by talking to our would-be users.
From the user all the way down to the output of our product.
When thinking in terms of products, we should be able to answer the following questions first:
- What is the problem we need to solve?
- Who is the audience we are going to solve this problem for?
Then we look specifically at the big picture and determine:
- Why are we doing this (what’s the vision behind it)?
- Strategy – the how will we do this?
Then we look at the jobs to be done and determine:
- Situation (When does this happen)?
- Motivation & Forces (I want to - what forces apply)?
- Expected Outcome (so I can)?
Finally we reach our outputs:
- What goals are we setting?
- What exactly will we achieve?
- What features will this manifest as?
- What will we do to reach our goals?
It’s vital that our process delivers a solution that solves the user's problem. Products become meaningful when the provided solution solves the specified problem. This solution describes the way in which a problem will be solved. Thus, the problem-solution-fit defines the core user experience of a product, the implemented features are extending this experience and support the core experience, but they cannot replace it. Visual and Interaction Design can make a product beautiful, easy-to-use, delightful and can even make it stand out from the competition, although they can’t make the product meaningful. This is why a proper problem-solution-fit is so critical for the success of a product.
Product Thinking enables us to ask the right questions, to build the right features and to communicate with stakeholders more efficiently. It empowers us to say “no” and to be hesitant before adding new features. Whenever a new feature is requested or someone has an idea for the product, we are able to ask the right questions, before drawing wireframes or crafting fancy layouts:
This will keep the product slim and effective.
We need to be improving our product continuously. It is also a way of working which fits into our iterative build-measure-learn approach and helps us to break down problems & work into manageable chunks.
To do this & have it be meaningful we need to measure as we go and one great tool for doing this came from the Toyota car manufacturer. It may sound odd to use something which was design for an assembly line, but it works in agile, lean product development, too – product kata.
Following the Product Kata helps us take small steps to learn about our customers’ needs, and start solving their problems faster.
Here is an example of a product kata spreadsheet to help focus the team on what they are building & learning.
We have a number of framkeworks we employ to help us build products. Like everything else, they are tools, to be used when needed at a certain time. They don't all work at every stage of the build.
This is a way of thinking developed into a framework to help make clear what job (or problem) your user is employing your product to solve.
Jobs are moments of emotional struggle & are solution agnostic.
The framework follows a basic structure of Situation, Motivation & Expected Outcome.
It is to help us clearly define, or make sure we understand the job a person is hiring our product to do. It is not a user story nor is it a persona. It is a specific framing of a problem to help us understand why we are building something.
If we do not have enough information to write the story, we know we then cannot begin to solve it & we must go back and gather more info; more research, more interviews.
- SITUATION (where I am/ what’s going on)
- When I want something to eat...
And I am not at home...
- MOTIVATION (forces/ anxieties/ pulls/ pushes/ worries/ desires)
- And I’m in a hurry...
And I have 1 free hand, only...
And I am STARVING (hangry)... [this is not a typo - it is hungry + angry :) ]
And I don’t know when the next time I will be able to eat again is...
- EXPECTED OUTCOME
- So I have energy to perform
Here, if we did not know all the motivations, then a sit down restaurant would work, but with all the motivations, the forces which push & pull us, we know something like a slice of pizza, a protein bar or perhaps a heavy, thick shake would do.
The workshop is run in a room, with as many of the different team functions as we can get, but usually capped at about 10 people. if any more than 10 are all actively involved at one time, it gets difficult to manage and to have enough time for everyone to be heard.
Like most everything else in this playbook, this is a guide and not a hard & fast rule. The outcome with this workshop is not only to make sure we can clearly define the problem and have enough information and understanding to do so, but to also get more team members involved and engaged in the process to understand, when it comes to it, how we framed the solution we are building.
Design studios are a method for harnessing massively parallel feedback from every team member in a way that can actually be absorbed.
Goals of the design studio
You can read & learn more about Design Studios from Big Spaceship.
The journey workshop helps people to understand how people will use, interact with & move through our products which we build. It helps to give a clear picture, to the whole team, and expose fail points, how we can help the user recover from those fails, decisions, and even new limitations in what we have developed so far.
Workshops are run similar to a design studio.
We get as many of the team members in, across all the function, up to about 10 people, and we begin to work on the journey.
Everyone starts individually and on a piece of paper. Using just boxes & arrows begin to draw out the journey a person would take with our product, using the problem we are solving which came out of either the JTBD workshop or from user interviews. This also helps us all to understand how much we know about our current restrictions & processes.
We then share the journeys and begin to compile a single journey, talking through all the points which differ on the individual journeys.
We use Job to be Done style interviews to get the the crux of a problem, a pain point a user has. We use them to understand their motivations (fears, anxieties, frustrations, hungers) for what they have done in the past. We use un-leading questions to get the user to tell stories from their past about how they have done things and what they have done or encountered.
These are open sessions to anyone one the team, so if you would like to sit in on one you can. Just make sure you work it out with the organiser first. Having too many people in an interview can make the person feel uncomfortable, so we try to keep it to two people max.
Running Discovery and Delivery in parallel and in a sustaining way.
A common challenge in managing the logistics of continuous lean product discovery is maximising learnings while driving high value and cost effective delivery.
Actually building and launching a product idea is generally the slowest, most expensive way to validate our ideas - our higher order objective in Dual Track Agile is to validate our ideas in the fastest, cheapest way possible.
Dual track is not new, it has been around for a few years and is used by many successful product teams. The technique coordinates two parallel, tightly coupled, work streams managed as two teams. Both teams focus on the same product, one team cares about product discovery and definition (discovery track) while the other build releasable software (delivery track).
The delivery track is a typical cross functional agile team. The discovery track is a team that represent the “product triad” i.e. business, design and technology. The discovery track has its own backlog and the delivery track has its own backlog. The output from the discovery track is validation and learnings which creates the backlog for the delivery track.
The process is not as linear as it may sound. Ideally the learnings from continuous delivery in the delivery track feedback into the discovery track resulting in a harmonious relationship between the two work streams.
Agile relies on the product owner being able to define stories and prioritise. The product track supports the agile process by providing workflow for the product manager to experiment, learn and adapt, leading to validated job stories. When implemented well the discovery track follows a lean process focusing on what to build without getting involved in how to build it.
A common concern expressed by teams that are new to dual track are statements like “this feels like big design up front”. Dual track is not a step towards the old days but instead, it prevents mini waterfall and sustains the agile process. Dual track clarifies team roles, product features and builds both transparency and accountability. The Discovery track is all about quickly generating validated product backlog items, and the Delivery track is all about generating releasable software.
We have learned from experience the importance of validating an idea before committing to building it. Validation is THE primary function for the discovery team, it’s their job to validate ideas and assumptions prior to the engineering teams commencing development. The question is no longer “can we build this?”, but “should we build this?”
When it comes to new ideas, features or even new products, we are by definition making assumptions—sometimes lots of them. We need to be as sure as we can be that the key hypotheses and assumptions underlying them are validated as early and as quickly as possible. Some of our assumptions will be wrong and that’s OK - what risk we are mitigating here is catastrophic failure from an unproven assumption that risks everything we are trying to achieve.
Validation helps us avoid the most common problem of spending time and money building something nobody wants - what’s often referred to as the “build it and they will come” mentality. Ultimately, if we decide we need to change course or pivot completely as we believe we are headed down the wrong path, it’s easier and a lot cheaper to change course sooner rather than later - preferably before the product is even built!
Many agile practitioners recommend getting straight to the business of coding and delivering working software as soon as possible - we at CH say working software is not a means to an end. If the software doesn’t add value to both our business and our end customer, then it’s just worthless code.
Design is a critical part of both Discovery and Delivery. Experience has informed our position that design cannot be left to chance and should not just emerge as a by-product of software development. To deliver a compelling, valuable, and desirable experience that hooks customers, converts them, and keeps them coming back, we know it is necessary to design our experiences in a different way.
We know that to create a desirable product with an engaging user experience, we should ‘steal’ bits from the most influential design disciplines — design thinking, service design, product design, graphic design, user-experience design — and apply them in our agile environment. We believe that design should be explicit, yet also be fully integrated into the product lifecycle.
We view design as a continuous process that starts in Discovery and continues in Delivery. The key with design is to do just enough to get started, to test with real users, iterate and make informed decisions about any change of direction as the product progresses through Delivery.
Ultimately, we feel that the design should be directed by both our business and our customers goals and always remains focused on delivering value. Our Discovery teams use facilitation techniques to drive out the key customer journeys and the design direction, while soliciting input about technical feasibility and business viability from the Delivery team.
As designers, we have come to believe that success lies in balancing a given set of goals or requirements - “perfection” does not define success—rather, the best outcomes and the most valuable design solution lies at the intersection of desirability, feasibility, viability and usability.
Usability testing refers to a method we use to validate our ideas or to test the execution of a concept, with representative users. Our goal is to identify any usability problems, collect qualitative and quantitative data and determine the participant's satisfaction with the product or a features implementation / value. Ultimately, we are trying to obtain a true reaction from a user, and understand what they are actually thinking—without causing bias in their answers. It sounds simple but there is of course, an art to it!
A usability test is loosely structured as follows:
Design of user interfaces for all devices, which includes desktop, tablet and mobile, with a focus on maximising the user experience. We focus on anticipating what a user might do and ensuring that the elements within the design are easy to use and understand, whilst also looking aesthetically pleasing.
UI Design makes use of fundamental disciplines from all other aspects of design, which form together to make your design successful. This consists of visual and graphic design, typography, copywriting, information architecture and photography.
For a product to be useful, it needs to have acceptable levels of both utility (i.e., whether it provides needed features) and usability (i.e., how easy and pleasant these features are to use). To design better, more useful products, it is important to stop designing solutions too early and start instead with product discovery: a process that helps the team better understand the problem properly so they don’t just design things better, but design better things.
Discovery is decomposed into three key tracks. Each one of these tracks requires different skills and it’s our job to ensure that our discovery teams should possess the skills to address each of these areas.
The purpose of customer discovery is to gain a complete understanding of our customer and their needs. All too often, product teams start development work on features without even knowing anything about the customer or the need it solves. Typical questions that need to be answered as part of the customer discovery process include, among others:
We know that at least 50% of software features developed and implemented are rarely or ever used. This represents a large cost to our organization, not only do we have to pay the cost of development but we must also pay for the cost of maintaining the software features moving forward. The goal of product discovery is to identify and validate the features that will deliver the most business value.
Even though our teams may have a validated customer need, if we can’t get users to adopt our solution to support their daily activities, then our product will not be successful. Building a positive user experience is critical for any product so we put user-centered design (UCD) front and centre in every discovery team. User-centered design is about discovery and research. We always start with gaining an understanding of the users and their activities and we build shared understanding with our engineering teams with early and continuous collaboration.
Technical discovery is the technical stream in the discovery process in a project. It’s the activity of identifying the problem context i.e. the business functional and nonfunctional requirements, the business system landscape (systems, owners, users, processes, interfaces, policies), and any other factors including scheduled changes to the above during the course of a project, assumptions and available technologies that altogether serve as constraints (either soft or hard) in shaping the solution to be delivered which must fulfill both constraints and requirements. The exit criterion for technical discovery is gathering of sufficient information to produce a technical approach which gives the direction for the architecture of the solution. The architecture turns into more detailed design during in the Delivery track. Technical discovery should result in a sufficient understanding of the problem to be solved and the constraints around it, to be able to enter the Delivery Track.
§Remembering that the purpose of product discovery is to discover and then describe the product backlog - product discovery is driven by the ‘discovery backlog’ which itself could be defined as a prioritised list of opportunities for the product discovery team to explore during the discovery track.
Ideas / problems to solve and opportunities in the discovery backlog can of course come from anywhere, but the three most important inputs are:
Each card on entering P2 should take the following format:
- What does the world look like if we solve the problem?
- Issue Statement
- One or two sentences that describe the problem using specific issues. It is not a "lack of a solution" statement. For example, our problem is that we don't have an ERP system.
- The process that will get followed to solve the problem. For example, DMAIC or Kaizen.
We find it helpful to use something we call ‘the feature buckets framework’ to help us build a well balanced discovery backlog - the framework is not explicit as to the appropriate distributions amongst the buckets we have defined nor how to prioritize internally within each but it helps qualify the value we think a ‘work item’ in there can deliver. We have a bucket classification as follows:
- Metrics Movers
- Features that will move the target business and product metrics significantly. There should be specific goals and strategies behind the decision to invest in a product or feature (things like AARRR metrics or HEART come in handy here).
- Customer Requests
- These are features that have been requested directly by customers. They are usually incremental enhancements, but it’s important to consider them or else risk alienating users or miss important feedback coming from their usage of the product.
- Innovative features that are internally generated based on insights in design or technology. Working on surprising and exciting features is important to delight customers and create a differentiated position in the market (Kano Model).
- Features that are included for strategic reasons related to learning or future goals (e.g. experimentation and data gathering).
Product design and development team are more typically focused on delivering outputs rather than outcomes. One simple way to change this behaviour is to enforce the statement of measurable outcomes (preferably leading indicators) before the team begins on their discovery / delivery journey.
The framework we use to prompt our team's thinking and discussion about the problem - solution options - then the delivery of experiments or engineering effort and finally, the measurement and adaptation before the feedback loop, is called The Möbius loop. It’s best visualized as a set two connected loops, one strategic and the other more tactical.
The left side of the loop sets the strategic direction in the form of why we are tackling the problem at all, the objectives, outcomes and the solution options. The right side of the loop is the tactical day-to-day delivery / experiment cycle. The model is not sequential but instead, it allows you to align the strategic objectives and measure progress against them.
To workshop our approach we use the The Möbius Loop canvas:
Discovery generates validated product backlog items in any number of collaborative sessions with engineers, designers and users over a time boxed period of up to 6 weeks.
Ensuring that the Delivery teams have everything they need to build a first version of the agreed solution is controlled by a strict definition of what it classifies as a suitably robust output from Discovery and what we call our ‘definition of ready (DOR)’.
The Delivery Team have one focus in life, work with our Discovery Team to build great quality features in the most optimal way. Our values are aligned to the Product Team in the sense that:
Connected Home is an Agile house, but we have to balance process and reporting with delivery, the later taking center stage. So if any processes are hindering us we can pivot and change our processes to suit the teams’ need.
Here are some points for moving your code into test:
Ready for release:
Connected Home is primarily a group of people who care about making awesome products. We hope the practices we've shared here will be helpful to you.
Thank you for reading.