Recently, thoughtbot started experimenting with offering one-on-one remote iOS coaching sessions as a service. After sending out a tweet asking if anyone would be interested and receiving positive feedback, we ran a one week Product Design Sprint to help validate and structure the program.
We are trying something
out:
iOS / ObjC / Swift coaching where you pair with our developers for
a few hours.
email coaching@thoughtbot.com
— thoughtbot
(@thoughtbot) January 9,
2015Understanding: Where We Started
We had a lot of questions and assumptions at the start of the week, as well as some ambiguity around what the end goal of the sprint was. We started by just trying to understand the program, users, our assumptions, and determine how we could help move the program forward.
Early on, we realized we had two types of users: the coaches and the students. We felt it was important to create an experience which benefited both groups so the program could be sustainable in the long term. We created problem statements for each type of user, which helped us define potential solutions later in the week.
During the understanding phase of the sprint, we wrote down our assumptions and organized them into three categories: coaches, students, and overall program structure.
These were refined quite a bit and explored through an assumptions table. This exercise allowed us to re-word our original assumptions and think of ways to validate them during the sprint. Here’s a snapshot:
Creating a User Story
At this point, we narrowed the scope for the week’s work.
We first created a user story:
- Student learns about iOS coaching somehow (tweet, blog post, etc)
- Student clicks on link to find out more information (landing page, form, etc)
- Student reaches out (through an email, form, etc)
- Coach connects with student and schedules a time
- The 4-hour pairing session happens
- After the session, we ask for feedback and potentially get a repeat student
We realized that some of our assumptions weren’t really testable this week, especially those having to do with the success of sessions. We will need to validate these assumptions as sessions happen.
For the sprint, the group decided to focus on a specific part of the flow, including managing expectations of potential students and onboarding, how to match up coaches and students, and how coaches would schedule their sessions.
Some concerns we were trying to solve:
- Coaches want some level of control over who they coach and when sessions happen.
- Coaches didn’t feel that these sessions would be productive for beginners, and want students to supply a project and learning goals. We wanted to use the sprint to explore ways to make sure that students were at the right level to get the most out of coaching and had an actual project to work on.
- We wanted to cut down on admin time in the form of emails, as well as trying to manage everyone’s expectations of the process.
Diverging and Converging
Part of our sprint was devoted to diverging, where we run a number of activities to better understand the problem and generate ideas for possible solutions. We ran through Mind Mapping, Crazy Eights, and Storyboarding.
Crazy Eights was an especially useful diverging activity for us. We each completed a series of quick sketches, and then participated in a silent critique and group discussion about the options. We were able to hone in on some of the stronger ideas, and made sure a stakeholder (a thoughtbot iOS developer) was present to give feedback throughout the process.
We also used Storyboarding to help converge on our strongest ideas and decide how to move forward. As a group, we collaborated on a series of storyboards representing different user flows. This helped us solidify ideas and visualize the process from the perspective of various types of users.
Feedback from Potential Coaches
Along the way we also wanted to make sure we had feedback from iOS developers who might become coaches. We checked in with developers at different points throughout the week, and even had a developer sit in on our entire sprint to give stakeholder feedback along the way.
Through this process, we validated if developers were actually interested in coaching and if they liked our approach to structuring the program. Frequent user interviews validated many of our assumptions, gave us new ideas, and helped us make confident decisions.
Takeaways from user interviews:
- Most developers have teaching experience and are very interested in coaching.
- Generally, developers like the idea of 1-on-1 remote sessions. The 4-hour block of time makes sense for most people.
- Multiple developers suggested having checkboxes with specific skills in the contact form, and then use that to tag cards on Trello so they could locate potential matches quickly.
- Developers didn’t want students to be able to request specific coaches, in case they couldn’t always accomodate.
- Most developers liked that there is some filtering happening, and that we have a way to “reject” potential students who may not be a good fit.
- Everyone liked the idea of requiring students to provide a project and a guide to what they’d like to learn ahead of time, and having some time before the 4-hour session to review this code.
Feedback from Students
We also gathered feedback from two students who already went through coaching, and we interviewed one potential student about his thoughts on the program.
“I think the [4-hour] session might easily have been worth 40 hours of my own time reading and experimenting with MVVM.” Ben, iOS Coaching Student
The feedback was very positive, albeit from a small sample of people. We decided to build a feedback cycle into the coaching process as a way to continue gathering information from students.
Sprint Deliverables
By the end of our sprint, we were able to provide:
- Research and guidelines to build the program with.
- A description of how users will interact with the program.
- Copy for a landing page and contact form.
- A functioning FormKeep form, with webhook posting to Zapier, which creates cards on a Trello board that we can manage.
- Templates for emails, including automated responses and guidelines for personal responses from coaches.
- Documented feedback from developers and potential students, as well as buy-in from developers.
- A plan for moving forward.
Follow-up deliverables:
We definitely wanted to see this project through to completion, so we had some post-sprint work to complete, including:
- A working landing page that we can direct people to with updated copy, visuals, and a functioning form.
- Check-ins with developers so they understand the process, can give feedback, and are ready to do coaching.
- Initial marketing via:
- A mention on Build Phase
- A blog post
As of Now, iOS Coaching is Live
Based on our research, interviews, and other activities during the sprint, we came up with a basic plan for how iOS Coaching can function moving forward.
Coaching will comprise individualized, 4-hour sessions that cover an iOS project that the student supplies. They will be remote, using ScreenHero, and scheduled by the coaches as they have availability.
Our sprint helped us create structure and assets for the program. Not only did we design a landing page and onboarding flow for students, but we were able to create a comprehensive back-end to the program, including organized Trello boards and feedback cycles. This will support coaches in their ability to sustain and enjoy coaching in the long-term and help students get the most out of the experience.
To learn more about iOS Coaching, visit our landing page.
To read more about how we run Product Design Sprints, view the Design Sprint Repo. Please fork it and contribute by adding your own exercises, and share your stories of successes and failures.
If you’d like to hire us for a product design sprint, get in touch.
