Most of our clients are building their first software products, and with that, most of our clients view software as a big black box. In other words, based on their knowledge of development they feel ill-equipped to make the right call. Typically, the client tries to make an association to something they can understand, like building a house or hiring a contractor.
As much as we would like to hear about their project, give them a fixed price estimate, and then build the finished product without any changes, it's never that simple. The thing is, we learn as we build. In almost every development project, we are working off of our client's assumptions about how they envision the project coming together. But more often than not new and better ideas come to light while working together.
In order to account for the unknown and provide the right amount of flexibility for our clients, we have implemented a system to deal with change, so naturally we call it "The Change Model". In every project there are changes being made, The Change Model gives us and our clients a simple process to evaluate the changes and tradeoffs we are making as we build products together.
The components of the change model
- User Value - The value and features that the end user experiences
- Design - How the user feels using the product, and in what order
- Tech Architecture - How many users are we planning on supporting during this launch? How often will they use the product?
- Budget - How much money is allocated during this phase of development? Who are the financial stakeholders? What needs to be shown to enable more funding?
- Staffing - Who is going to do the work, and in what capacity?
- Schedule - What dates are we trying to deliver the product for? and why?
- and the tie-breaker is the Vision and Decisions. This component looks at the goals for the product and makes sure the decisions made are still in alignment with the long term vision.
Rope connecting components
You can think of each circle as it's own entity, a component of the overall product. Each of these components are tied to each other by a single rope. A rope is a perfect metaphor because it has tension.
A successful product development process has tension in the system. It's healthy. The system starts to break down when there is too much or too little tension (slack) around each component. Too much tension snaps the rope and the product falls. Too little tension and there is nothing holding it together. If each component doesn't work together the product won't feel cohesive.
Advocates for each component
In order to ensure that each component is being considered as decisions are made, we assign each component an advocate. An advocate's job is to make sure that he/she thinks about how a change may affect his or her's component. While each component needs an advocate, the same team member may be an advocate for more than one component.
As any product grows and matures, the size and needs of the product team change drastically. A startup building an MVP might have a founder, designer, and developer splitting the roles and responsibilities. At the enterprise level, a product may support millions of users and each component could have a team of people being its advocate.
The Benefits
Since we have implemented the change model, we have noticed a couple positive things taking place:
- Our clients and our team are speaking the same language.
- The process allows for flexibility in times when it's needed most.
- Decisions are made out in the open vs. in a black box, and everyone understands the trade-offs of those decisions.
- Clients become extremely valuable members of the product team. They have a new found confidence about what they have built, and they often walk away with a process to continue development with their own internal teams.
While the change model may never be perfect, we, at Differential, have found it to be an extremely valuable communication tool that's helped us further our quest to be Built for Change.
A huge thanks (and credit) goes out to Slack's first product manager, Kenneth Berger, and his post The Six Forces of Product Development for providing the inspiration and experience with implementing this internally at a fast growing company, like Slack.
