This document helps Infinitas Learning to define how we deliver digital products to our users. It covers the roles that each member of the team will play during the software development process and lays out the process we’d like to take from idea through to delivery and learning.
We have a responsibility to ensure that our products focus on customer needs. If we don’t know what the customer wants, we will build the wrong thing. We must validate our assumptions, research, test, and talk to users. We must have empathy for our users but be aware that what they ask for isn’t always what they need.
No matter how much we feel that we know our users, the real world usage patterns of our products should drive our decisions. Analytics must be built into the system from the start, and we should be using prototypes, iterations, and rapid delivery to ensure that we are learning and delivering useful features that our users love.
Each Infinitas Product team is a team of people working on a single well-defined product or product group and set of explicit outcomes. A team forms the heart of delivery and will always deliver more than an equal number of independently working individuals.
Each member of the product team has an equal responsibility for the delivery of the product according to strategic business and customer needs. We recognize that there are specialists in each team, but overall each person can contribute to their level of comfort and ability regardless of their job description.
The quickest way to learn is from failure and mistakes. We need to make small, rapid bets which show us where the issues really are. Rapid iteration, testing with our users are good ways for us to quickly find and learn from our failures. Nobody gets in trouble for failing; they get in trouble for not learning.
For every good idea we could build, there are 5 better ideas that weren’t thought about. We need to look at development time as a limited resource and ensure that we are using it as effectively as possible. This means we should be conducting user research, paper prototyping, and more in order to ensure that the ideas that do get to the engineering team are at least somewhat validated.
User experience is not a thing that you can stick behind a role ‘UX Designer’; user experience is the product. Beyond the user interface, the user experience is impacted by performance, bugs, and unneeded features or complexity. A great user experience belongs to the entire team.
In order to fit with the above principles, we need to think of a different set of roles and responsibilities for each member of the Product Delivery teams. As a note, the product itself is owned by the team as a whole and not owned specifically by any one individual, no matter what their role is.
A product manager owns the relationship with the customer and business stakeholders. A product manager does not get the final say, but rather is an equal member of the team who specializes in discovering user needs and communicating those needs to the team. It is then up to the team as a whole to translate user needs into deliverable technical solutions.
A business analyst is most useful when handling features that require changes to existing business processes or by interacting with the customers to understand how they might change their processes to better use our tools. A business analyst is a tricky role to understand within a customer facing team, however, they should not be the team scribe responsible for writing things down.
A designer is a team member who specializes in creating user journeys that surprise and delight our users. They will be working closely with both the Engineers & the Product Manager to understand the user needs and create technically achievable visual designs in an iterative fashion.
The engineers at Infinitas own the technical implementation for the product they are working on. This includes, and is not limited to: architecture, monitoring, deployment, quality, technical debt, automated testing, and other implementation details.
A quality engineer is a subset of engineering which focuses on the quality of the product as a whole. They, like the engineers, own the technical implementation but spend more of their time focused on improving the quality processes of their team
The delivery process starts with an idea. A thing that we want to build. An idea comes in a variety of forms (usually bugs fixes or feature requests) and can be represented by a user story, epic, or bug report. These can come from a wide variety of sources throughout the business including but not limited to: strategic business direction, user research, focus groups, product team suggestions, or bug reports. Regardless of the source, we must put in the same level of focus in validating and prioritizing the idea.
Validate the idea:
These questions do not all need to be answered for every idea that comes through, but it is critical that they are thought about. Once ideas have been validated, they should be put into a prioritized list. Refinement should not happen for any ideas that are not going to be developed within the next 2 - 3 weeks.
Refinement is where a validated idea is turned into work for the engineering team. Ideally, this is in the form of an Epic or Feature. Bugs can skip this step as they should already be well defined and well understood. If we are debating the value of a feature or epic during the refinement stage, then we didn’t do the job properly in phase 1.
The ideal mechanism for Refinement is an Epic/Feature kickoff. The idea here is that you bring all relevant individuals into the same room (or remote chat) and discuss the work required to deliver the Epic/Feature. The output of an epic kickoff should be a set of deliverable pieces of work. If this will take more than 1 - 1.5 hours the Epic/Feature is too big and should be broken down into smaller pieces.
The initial design work for a feature or epic should have been done prior to the refinement stage. Any further visual design work should be additive to these initial designs. As you should have a general idea of the work requiring visual design work, it is possible for the next phase to initiate without this being complete. Iterating on designs is also perfectly valid so we shouldn’t be afraid to go with a visual design that is good enough and come back to it to make it better on a subsequent iteration of the work.
The visual design does not need to be approved, signed off or validated. It simply needs to correspond with the requirements identified in the refinement phase.
Technical analysis is the phase where any key architectural decisions should be made. For many features or epics, this work will be done as part of the epic kickoff. For more complex features or epics, this may include proof of concepts (though complex POCs or spikes should be built prior to an epic kickoff and are part of validating the idea).
Rather than heavyweight documentation we simply need to have a discussion involving all relevant engineers. The required documentation is simply enough to ensure that everybody knows what we are building. Generally, this detail can be added to the relevant PBIs in order to keep everything together.
Questions to answer:
This is the phase where we commit to the idea. Once this starts the idea will go into production. If we are not 100% certain that we want to deliver a feature into production then we shouldn’t start building it. The development phase should be kicked off with
The development phase includes all aspects of software development required to make high-quality products. This includes, but is not limited to:
The key aspect of this phase is that rushing it will only slow us down long term. There are a certain set of technical tasks and practices that MUST be completed or we will find ourselves in a position where we move slowly and are failing on delivering to commitments.
The deployment phase is when a new feature goes live to our customers. This phase needs to be as repeatable, automated, and pain-free as possible. The long term goal is continuous delivery where we can deploy things to live at any time of the day or night. The reason that we MUST commit to going live before development begins is that it is exceptionally expensive to build things. Once we’ve decided to start building a feature it must go live or we’ve wasted our time and money. This phase should be in the hands of the engineering team and we should be focusing our efforts on making deployment as safe as possible to avoid impacting our customers when things go wrong.
Using master based development we must ensure that all changes pushed into master are safe to go into production. The basic rule that all engineers must follow is: every commit in master must be safe to go live. When we do this we ensure that we can always fix forward easily. Ie: when a bug is found, we can simply make the fix in the code without worrying whether or not the current master branch is safe for production.
There are cases where a deployment goes wrong and critical errors go into production. In general, the rule is, if we can’t identify and fix the problem within 15-30 minutes we should be rolling back to a previous version.
An effective continuous delivery organization doesn’t function on intuition. We must be able to monitor the features and ideas that we have delivered. This means taking the time to build this into the features even if it means delivering fewer features overall. There are two types of monitoring that are critical to have in place.
Functional monitoring is where we make sure that our product is working. Generally, this can be in the shape of generic metrics (response times, CPU utilization, response codes, error rates, etc) or domain-specific metrics (emails sent, users registered, etc). Both of these types of metrics are important to consider when setting up functional monitoring. The key goal when considering functional monitoring is that we should know when something is wrong before the customer does. This means that critical functions must be covered by automated alerts that fire when things go wrong. It additionally means that when these alerts go off they must be addressed. Functional monitoring falls over very quickly when we start to ignore the alerts.
Business monitoring is what we use to ensure that our product is functioning effectively. Each and every feature we deliver should have a mechanism for us to understand if it is working effectively. We can use this data to learn from our customers and their real-world actions, to understand the overall health of the system and to provide data to decision makers throughout the business. Business monitoring also allows us to understand the health of the system. If a feature or redesign reduces engagement this should be identifiable with our business metrics.
The final aspect of product delivery is learning. If we do not learn from the features that we deliver we are doomed to deliver mediocre products. To learn we must talk to our customers. Our customers must drive what we build next and how we build on top of the features we’ve delivered. There are a variety of mechanisms that we can use to understand our customers and learn from the features we’ve delivered:
To bring the product delivery process full circle, we must learn. Iterative, agile development isn’t simply about wrapping iterations around a set of ideas we come up with. It’s about working with the customers, understanding them, delivering small working pieces of software, and learning from each delivery to continually grow and improve.