Way to Health (W2H) is a digital platform that enables clinicians and researchers to test and implement health care interventions with minimal effort at low cost. Since its start in 2009, W2H’s small but nimble team has supported more than 280 studies and clinical programs and continually iterated on methodologies for optimal product development. 

In this Q&A, Michael Kopinsky, the director of product development at W2H, reflects on process changes that have empowered his team to work more effectively. Responses have been edited for brevity and clarity.

 

First, tell us how the W2H team is structured. Is that structure typical for teams running a tech platform? 

W2H is divided into two groups. The operations group works directly with clinical teams, study teams, and staff at CHTI to define opportunities to improve health or health care and design interventions to be delivered by W2H. The rest of us fall into the development group, where work is focused on platform performance. We build features and figure out what the next features should be. Some of our work does support specific programs or research studies, but as much as possible, we try to make changes that are broadly useful.

 

The development group has tried out several product management methodologies over the years. Tell us about those changes and why you made them.

Our approach has always been based on the principles of Agile software development, but the specific Agile methodology that we use has changed. When I started nine years ago, we were using Scrum, initially with one-week cycles that later changed to two-week sprints. Then, around the advent of COVID, we switched from Scrum to Kanban. Scrum is oriented on meeting commitments and fixed time boxes, whereas with Kanban you focus on reducing work in progress by completing in-progress tasks before picking up the next-most important item in the work queue. 

Kanban positioned our team to be reactive to changing needs. This approach was invaluable for responding to COVID because we didn’t have this fixed idea of what to work on for the next two weeks with a “thou shalt never change the scope in the middle” mindset. Urgent things came up, and Kanban allowed us to change assignments and scope when needed. However, the downside to this period of time is that we were being pulled in many directions. Rather than working on a concerted set of high-impact features in a coordinated way, we were working on lots of small, scattered things, which is not great for team morale or building high-quality features.

 

More recently, you’ve turned to the Shape Up methodology, which uses longer cycles comprising a “build” track in tandem with a “shape” (planning) track. What led you to adopt this structure? What does it look like at W2H? 

That happened around January of last year. I'd seen talk on Twitter and elsewhere about the Shape Up methodology, and I thought it would be a good match for what we hope to accomplish at W2H, namely, to carve out the space to think about and develop bigger, more transformative solutions.  

The “shaping” is done by me and our product manager, Michael Josephs. Shape Up forces us to ask what is worth spending six weeks of effort on and come up with big six-week goals. As the name Shape Up implies, what we hand to the developers isn’t fully fleshed out; we define some things in advance and hand them the general shape of what the work will look like. There are parts that need to be evaluated up front, but as much as possible, we leave discretion to the developers in how to implement the things that we’re working on. 

After the shaping phase, the development group and W2H senior leadership review our pitches and decide which ideas to work on next. That’s the betting phase. Our developers then spend the next six weeks building and refining the solutions that we bet on, while Michael and I return to shaping ideas for the next cycle.

 

You’ve been using Shape Up for more than a year now. How well is it working? 

It has been very successful. Our developers are more engaged – they like working on high-impact things, and Shape Up gives them the right amount of autonomy and direction. And it forces Michael and I to think, “How are we going to sell this idea to them?” We know that if the developers aren’t sold on an idea, they'll tell us. We work to create the kind of team where that kind of pushback is welcomed. 

Shape Up also encourages us to think at the right level of granularity during the product planning process. It would be futile for us to come up with what we are doing for the entire next year, but it would be similarly a waste of time for us to specify what we are doing tomorrow and the next day. The six-week approach helps us take on big enough – but not too big – chunks of work and make bets on things that could be high impact if they pan out but not too risky if they don't. 

With a longer cycle, we can get things into production quickly while still having time to iterate. In that time, we’re not just releasing the feature but also starting to use it, and that means we’ll know which things to circle back to sooner.

 

What advice would you give to other software development teams about finding the right way to work? 

There's no one-size-fits-all solution. Try different things; don't stick dogmatically to the way things are “supposed” to be done.  

There are far too many teams that work in a Scrum context because that's all they've ever known and because the “rules” say that you have to do it that way. For example, one rule of Scrum is that you have to have a daily standup. For a lot of teams, a daily standup is the right thing. But many teams have daily standups that aren't effective and that everyone hates. If you never experiment with taking standup away, then you can't validate its value or discover what could be gained from its absence.  

At W2H, we have eliminated our daily standup and replaced it with other mechanisms that are more effective at getting at what it was meant to accomplish. Eliminating standup was a scary change, but I’m glad we tried that. 

With all things in process, you need to be willing to experiment and see how things go to make sure that you're doing what’s best for your team.