New project? New team? Start here.
Starting is hard. But, it is one of the most important things that any team can do. Not because of the need to get work done, follow a plan, or reach a goal, but because starting gives people the opportunity to learn.
I’ve never been on a project that doesn’t evolve or pivot almost immediately because of information uncovered in those first days of development.
Change is inevitable, and the byproduct of assumption validation. We all make assumptions about what we think the market or end-users of our services or software want. But, without starting, we can’t gather the evidence needed to validate our assumptions, learn from mistakes, and pivot to fill a market gap.
In addition, projects, companies, and innovation labs need runway time to hone in on their market differentiator or find a cadence. Starting sets the beginning of the learning journey.
I hear this a lot from creators, entrepreneurs, and teams: they sat on an idea for years before taking the first steps, and they regretted waiting because they lost valuable learning time.
Much like compounded interest, the insights that come from compounded learning are difficult to catch up with once you’ve been left behind.
In a worst-case scenario, there is a risk that someone else will start with a similar idea and evolve into the market space meant for you.
What activities help teams start?
Activities that facilitate a rapid start are quick-starts, kick-offs, hackathons, project inceptions — there are many names for these starting workshops; and, all can be facilitated remotely using collaboration tools like MIRO, Coogle (with a “C”), MindMeister, and Jamboard if you already have Google Enterprise.
During these workshops, the team needs to walk away with a shared understanding of the following five things:
- An understanding of team roles. This is not the job title that a person has, but rather it is the role that that person plays as part of a cross-functional team. Calling this out explicitly, in the beginning, helps alleviate power struggles in the future.
- An understanding of a believable directional goal. What is this goal? Once defined, the entire team needs to focus on achieving this goal. Without this, people will naturally drift towards personal objectives. This causes confusion and takes precious brainpower away from the team and company.
- A high-level understanding of the work to be done — and where to start. Once everyone understands the directional goal, they can define and plan the work that needs to be done. Included in this definition is an understanding of who the work is for (the user), their pain, value, and most important place to start.
- An understanding of the success metrics used to measure progress towards directional goals. Once you know where to go, you need some way to measure progress towards that goal. Without this, you can’t ask critical questions along the way (e.g. why have we not reached our goal). Plus, how do you know when you achieve a goal and can celebrate?
- An understanding of the ways of working. If one team member is focused on Agile practices, but another is working in a Lean way, and yet another is spending a ton of effort on upfront design — you will quickly have a culture clash, and work will grind to a halt. Defining the methodology, the ceremonies, and ground rules go a long way to help alleviate future culture clashes.
You’ve started? Now what?
The next step is to roll-up your sleeves and start dogfooding.
Dogfooding or “eating your own dogfood” is when companies exclusively use the software that they built. I can’t stress the importance of having people poke around in software in those early days of development. This practice enables teams to find glitches, strange experiences, and get to know the software they are building.
Dogfooding will be ugly, painful, and disappointing. But it will give you insight into the experience of your customer and allows you to pivot with grace.
The next step is to engage early adopters. During this period, you can ask the customer if the software has met their expectations? Has the software helped them achieve their goals? Is it providing value? If the answer is no, then you have work to do.
Finish fast and finish well.
If starting is hard, then ending is even harder.
If, during your starting journey, you discover that your idea is a dud, it provides no value to customers or is simply not technically feasible, kill it, learn from it, and move on. There’s no need to hypothetically “beat a dead horse.”
The secret to finishing well is to find the space between killing an idea too quickly and continuing because you don’t want to let go. Finishing is done with intention and with value in mind.
There’s no magic indicator that tells you when to finish, but there is a sweet spot where you notice that the effort put into the development is no longer helping you reach the directional goals defined in the starting workshop.
When you see this spot, it’s time to have a mature conversation about value. If you don’t have this conversation, the company is at risk of making an expensive mistake and creating the churn that comes from indecision.
