Dr. Kelly Starrett coined the phrase Supple Leopard. It comes from the observation of how leopards are powerful, fast, adaptable, and stealthy. He’s taken this understanding and has applied it to improving human mechanics through physical fitness – More specifically, mobility training.
Teams should be powerful in their will to solve a problem. Adaptable and quick enough to make changes with very little disruption. Lastly, they should be strategic in their decisions.
I believe in order for products to achieve the momentum it needs, product teams have to work on exercising their ability to deviate quickly (but with reason). That reason is based on sense of direction and understanding of the customer and users that interact with their product. The exercise I’m referring to is not the gym- it’s research…which improves your cognitive activities around building a product that is viable.
Don’t follow me, I’m lost too
Velocity is a common metric in software development, however, what does it actually mean?
Velocity is the relationship between speed and direction. Velocity = Distance/Time
When building products, “distance” is measured by the amount of value delivered to a customer. The more value you deliver, the “farther” you’ve gone.
In other words, velocity is measured by the number of marketable features delivered to the customer within a specific unit of time. It’s about how fast we head into the direction of value. We can work fast, but if we’re not heading towards value, then our velocity would be low, despite our high speed.
Velocity determines predictability, and not productivity
Product development teams typically measure velocity through tracking what work has been promised versus completed.
Velocity is typically measured as an average of the output of the past several sprints.
The more sprints you’ve included in the calculation, generally, the more accurate the velocity and thus the greater accuracy with which you can predict the delivery of future value.
Ideally, teams shouldn’t have disruption in their series of sprints. These disruptions distort the determination of an accurate team velocity.
Evaluation of velocity should be continual. Over time, given a stable team and management structure, velocity becomes more and more accurate. Moreover, the composition of your team shouldn’t change dramatically. If it does, you should understand how it’s affecting the team’s understanding of scope of work.
I’ve worked with a team that estimated level of effort inaccurately. This was a huge struggle because the team was not having frequent discussions to break down scope of work. The solution was allocating at least 1 hour 3 times a week for problem/solution discussions. We set time during the sprint to explore proposed solutions further. This resulted in deeper understanding and more accurate prediction of effort level.
Lock and stock with three smoking team members
You can’t accomplish all things that are needed in product development without a team. Each participant plays a major role and you should be vigilant in respecting the behavior, perspective, and skill that is needed to contribute to a very complex delivery strategy.
The make-up of a strong team
Researches behavioral patterns and explores an applications ability to resolve user-centric needs. This person will help deliver visuals which is supported by
user behavioral data.
Breaks down large solutions into more doable and easily achievable discussions. An
engineer would investigate technology solutions that can support productivity.
Responsible for building a successful product. This person shares the vision, strategy, and works with the team to set achievable and measurable goals.
This multidisciplinary team is responsible for delivering a product. I’ve seen teams perform better when each individual holds themselves accountable for their role. Furthermore, the team performs a lot smoother when their ranks (titles) are flattened. Meaning, no one reports to the Product Owner.
Market opportunity and pain is not fully defined
I’ve worked with many teams that would jump directly into building software without fully understanding the customer, and users that will potentially use the product. I’ve seen products die a slow death when features are built for the wrong segmentation.
A tone-deaf focus on features instead of customer value leads to product misdirection and waste. Ron Jeffries defines value as “what we want.” However, “what we want,” is really to be delivering an improvement to the customer’s experience — and the customer decides what that means, not us!
Initial work can also be done in preparation of a broader group discussion. Meaning, you do research by interviewing your potential users. During this time you should be focused developing a story around the people you’re talking to. The more conversations you have around what you are trying to offer and the solution it is solving, the more refined your story will be as you continue to progress.
I have a UX/Researcher on my team. She gathers a lot of great intelligence by interviewing more than a dozen users. These interviews are recorded via phone or computer. Open ended questions and behavior interactions by the user are evaluated and archived. The team later evaluates and discusses their assessment and applies it to problems that we’re trying to solve.
Identify opportunity, pains, and solutions
Before we go into customer discovery, I want to pause, and make sure you’ve first locked in your business model. This will help as a supporting role in setting business goals. I’m specifically talking about value proposition.
A helpful exercise in determining your business model is Business Model Canvas by Alexander Osterwalder. It’s a great method for aligning operations, marketing, and sales. If you do not have a clear business model, or your business activities are not aligned, please go through the BMC exercise. To learn more about Business Model Canvas and how to apply it to your vision, purchase Business Model Generation at Amazon.com.
Impact mapping is what I use with entrepreneurs, product and engineering teams. It is a process in which you can prioritize the most impactful goals that relate to your business or customer. These goals have associated metrics that should be measured on a frequent bases to make sure you are close to achieving the outcome that is expected. You can learn more about Impact Mapping by buying the ‘Impact Mapping: Making a big impact with software products and projects’.
Value of measuring a variable is often inversely proportional to the attention it gets. — Douglas Hubbard
Most teams or entrepreneurs have an unlimited amount of things they want to accomplish. However, you need to narrow it down. There’s no way you can accomplish everything at once (you know this). You may go through your shopping list of goals and then prioritize them once you’ve defined the why, who, how, and what. Once all of the measurements, goals and objectives are defined, start voting on what is critical (most impactful) or easy to do (low-hanging fruit). Only focus on one or two goals. Archive the rest for later evaluation.
Your goals should explain how it will make an impact on what it is you’re trying to achieve. Lastly, your objectives should be measurable.
Goal: Achieve more sign ups for a demo of our product and services
|Attract more quality users to our homepage (highlight value of product and services)||10%||13%||20%|
|Increase demo request signups||2%||5%||10%|
Customers and users personas
How much do you know your customers? In an effective design process, personas are made up characters representing types of users that interact with your product. They’re a good way of describing the profile of your customer base. Creating personas with your team also helps build shared understanding of who you are delivering software to. Go through the psychology behavior of your customer, and all of their goals, capabilities, and contexts around your product.
Personas put a personal human face on otherwise abstract data about your customer. Your product development team will have better understanding of what a real person might need. This helps with brainstorming and defining features.
Customer journey (“Now”) mapping
One of my favorite mapping sessions is customer journey mapping. It’s gratifying to comprehensively understand the path of customers. Knowing where they’ve been and where they’re going is an insightful exercise.
Customer journey maps are illustrations that visually demonstrate customer needs, the sequences of interactions that are necessary to accomplish their efforts, and the resulting emotional states a customer experiences during the process.
Map your customer’s activities as it stands today. Interview as many customers as possible. Ask them about their journey, and dive into each milestone that has made an impact on their decisions. Ask about their thoughts and feelings as they describe each task and consideration.
The above diagram represents a timeline from the beginning of a phase to the end. Journey’s would have multiple phases. The graphic above only represents one of several phases. The icons represent an experience, while the gradient colors represent emotional state (bad-good), which includes thoughts and feelings .
Building your product roadmap
Establishing your business, goals and customer needs is no simple task. It takes real collaboration from experts that understand their domain. Your team will help make this process effective when theirs overlap among the groups experience.
Once goals and objectives are defined, the next natural step is to start building a high-fidelity roadmap. My recommendation is to take the one or two business goals from your impact mapping discussion.
Example: Converting an objective into a high-level roadmap
Goal: Achieve more sign ups for a demo of our product
Objective: Increase demo signup by 20%
Layout a workflow or general actions needed to accomplish your goal. Layout the solutions horizontally as if they are linear steps/actions that need to be taken.
Continuous strategy and tactics keep the development pipeline full
The product development process is continuous. Meaning, once you start those gears, it should move forward with no disruption. The momentum of parallel processing specifications, design, implementation, testing, and validation is endless.
These customer development methods help build shared understanding and purpose for the product development team. That in return improves product and engineering’s productivity. Now, when you have that and you have clear set of goals, the team will have a fighting chance to improve velocity through continuous learning.
Over time, you too will become a Supple Leopard.