In our first post, we discussed how to assemble the correct project team to ensure a successful delivery. Once all the right people are together, it’s time to put them in the room and get the project underway. For us, that begins with a kickoff meeting.
Setting the kickoff agenda with research
At Umbrage, we often step into a software product that has already undergone several iterations and has not found success. The initial step that most product teams miss is conducting a thorough discovery process to truly understand the business needs and opportunities for the features that will be built by the team.
When we kick off a project, we usually do an initial workshop that is one to two full days that combines relationship building with outlining the needs of the user we will be building the software for.
But before we walk into our initial kickoff workshop, we have done our damnedest to do as much legwork as possible to “frame the conversation” that will kickoff the session. Who we are — both Umbrage and client — why are we here, what is the context of this project, what are the goals, the milestones, the measure of success; and we begin digging into further defining those things by talking about the actual user. Walking into the kickoff meeting armed with that depth of knowledge is like coming to the first day of school knowing you did all your summer reading. Did you finish reading Edith Hamilton’s Mythology? Good, because there’s a pop quiz the first day of class.
It’s a great feeling to sit down with a project team and stakeholders and start talking to the client about their business, their challenges, who the software product is for, and why they have embarked upon building this software. It shows commitment, care, and consideration. It shows we’re here to build something together and we’re here to dig deep and really understand why and for who we are doing this.
Discovering the Journey
The first week is the true kickoff time. Some initial research and discussion has already happened and all the correct folks are at the table.
The structure of the kickoff meeting is crucial to setting the stage for the project’s success. Having an agenda that is organized and outlines the project’s goals will help keep the time productive. This includes allowing team introductions to build rapport and establish relationships as well as high-level goal setting and alignment.
Having the end users in the room, at least during the one-to-two day kickoff, is ideal and hugely beneficial. If you can’t do that for some reason (and the reasons are many in this busy, remote world we live in these days), then make sure that your proxy representation really knows the end user. And make sure that they are empowered and accountable for speaking on the users’ behalf.
Now that we’ve kicked things off, we’re all cozy and have talked in a conference room or on a Zoom, we’ve gotten over those initial talking-to-new-people jitters; then we get into the details with a few different exercises that tell us more about the purpose behind the software we intend to build: some business challenge/opportunity/value activities, evaluating the existing system or app we may be integrating with if there is one, drawing out a high-level app flow of the user’s journey through that ecosystem, then really digging into that user journey to understand the specific actions the user is taking and the end goal they are trying to reach in doing that.
This will be the foundation for everything that comes next; for all the wireframes, for all the UX/UI mockups, for all the user stories we write, and ultimately all the things we produce to get us to a dev-ready backlog state to start developing actual software.
Now that the initial plan is set and the team is aligned on goals, desired outcomes and the overall roadmap, it’s time for devs to open up their console. Or is it? In our next post, we’ll break down the first steps to “Getting Dev Ready.”