Our company is different from Basecamp in two significant ways that (I think) should impact the way we employ Shape Up. I’m curious if anyone else has navigated the following:
Assigning Shapers to focus on a specific product (or area of a product)
Bridging the UX design gap between product strategy and execution
We are a venture-backed company and plan to multiply our efforts this year, meaning that one or two people pitching projects could easily become a bottle neck. We are currently nowhere close to having the kind of “portfolio of ideas” basecamp has on hand during each betting cycle.
Most of the Pitches I’ve seen (from basecamp or anywhere) don’t really incorporate any user research. While I definitely think that a lot of user research is theater, I’ve also participated in lots of research over the years that has been incredibly helpful and insightful.
Anyone have experience incorporating a design research practice into the Shape Up Model? I’m thinking of the kind of discovery process that is less about innovation and more about usability.
Hi Matt, I think our situation is comparable. We’re also venture backed, but more importantly have two core products (each with their own product manager) and regularly do involve usability and value testing practices in the discovery work, i.e. on the Shaping track.
Us product managers are the main ones responsible to shape work that can be bet on for each cycle. I usually have 3-5 ideas that I’m shaping simultaneously. Those range from big, strategic projects with high stakes to smaller, less risky ideas. I’ve felt that the 6 weeks cycles, which we do, afford enough time for this kind of discovery work.
As to your question on design research practices: A couple of times, I’ve worked with a designer to actually shape an idea and go beyond fat marker sketches or breadboards to produce actual high-fidelity prototypes w/ Figma. These prototypes could then be used to run value tests and usability tests with customers. Oftentimes, we’d feel like we were able to either confirm an initial hunch or learn that we need to refine an idea.
Sometimes, we later broke the designs down a level of fidelity again (to sketches or wireframes) for the cycle team, or included the designer in the build phase and used the hi-fi designs as a starting point to iterate on.
In addition to such user tests with prototypes, I’ve also run two design studio workshops to include a customer success team in coming up with starting points for solutions to complex problems for which they were the domain experts.
Again, the 6 week cycles always seemed to allow enough time for shaping a handful of projects at once – some of which require more extensive research of various kinds, and some of which require less or no research because you just know what to do.
Hope this helps, looking forward to hearing other peoples experience with this!
Sure! It’s not a problem. Just define your appetite for the deliverable of your research. Ryan Singer, author of Shape Up, usually defines a pitch as a shaped up feature which needs to be designed and implemented, but the Pitch can be the “shaping up” activity itself. For example, say you want to shape up a new home page experience, design a new robot hand, or prototype a loyalty program for your ecommerce site.
Decide your appetite for this task. For example, “We want to prototype a new loyalty plan for my online shop, and our appetite is 120 hours” (a three-person team working for 5 days). Once this pitch gets past the betting table, you proceed to tackle the problem to design the best loyalty program you can within the allotted five days, this can of course include as much customer discovery as needed.
For a structured design thinking process, I highly recommend the book “Sprint” produced by Google Ventures.
While I get the principle of what you are saying, something about it isn’t sitting right with me. Here is one issue I see with this approach…
With only 5 days budget, they could only do as much discover as they can within that time, which may not be the amount that is needed. Having an appetite to shape something is fine, but having an appetite for validating it doesn’t seem right to me. This might change from company to company, but I’ve worked at places that took 2-3 weeks to recruit the necessary people to do usability tests, so putting a time budget on something that people wouldn’t have a lot of control over doesn’t feel right to me.
Because shaping operates in the unknown space, I think it should be more opportunistic and ideally avoid having appetites on it, if you can. Otherwise you risk rushing things and bringing badly shaped work to the betting table.
Well my specific numbers were for illustrative purposes. If you need longer time frames, by all means adjust accordingly.
I don’t know anything about your organization, maybe you’re testing medical devices which have very stringent requirements, but surely there are some constraints and limits on your resources. Maybe it’s 500 hours or maybe it’s 2000 hours, but if you don’t put any appetite on it at all maybe you’ll end up spending way more time and money on usability testing than it warrants, diverting resources away from other priorities.
Because shaping operates in the unknown space, I think it should be more opportunistic and ideally avoid having appetites on it, if you can. Otherwise, you risk rushing things and bringing badly shaped work to the betting table.
I feel the opposite. I think creativity loves constraints. People waste so much time! Having time constraints can really help focus and drive you toward a more structured designing thinking process.What if you only had 8 hours to test your design? Maybe instead of spending weeks developing your usability test, recruiting people to administer the process, and pulling together dozens (or hundreds?) of customers to evaluate your designs, you could simply get feedback from 5 people, this afternoon? And then 5 more people tomorrow. Sometimes you don’t need 300 people to tell you there’s an issue with your design, you just need a few. Watch this two-minute clip starting at 48m. It talks about the decreasing returns of user interviews based on hundreds of studies
100% agree with your point around sample sizes. When I’m doing interviews I aim to speak to 8-10 people max. So the idea of wanting to get feedback from 300 people sounds like insane overkill to me and a very poor use of time. Personally, I’m not a huge fan of usability testing in the first place, but that’s probably an entirely different conversation
I also agree with your point around constraints & creativity, but for the shaping process this still doesn’t feel right to me. I think the reason is because a deadline has the unsaid expectation of delivering something at the end and one of the points about shaping I found really important is that no commitment has been made at that point.
In reality, we aren’t going to be able to successfully shape everything that we start shaping, so we should be free to put something on a shelf and move on to something else. Maybe we’ll come back to it again someday, maybe not. If the time constraint is self-imposed I’m all for it, but if it’s company imposed with the expectation of a pitch being delivered by the deadline, from experience, I’ve found that often ends up in some not great pitches.
I appreciate this doesn’t resolve your point around people’s focus, which is valid. But again, because shaping is in the unknown space that means it cannot be brute forced. Having focus is obviously important, but it doesn’t guarantee you’ll be able to shape a good enough solution in the time allowed. That’s part of the reason the that while the shapers work in a parallel stream to builders, I don’t believe they should work to the same time-boxed Cycles rhythm. Thanks for sharing the resources btw, it’s a good discussion
I’m hearing there is perhaps a bit of fear around the possibility of failure, but does it help if you can embrace the fact that some bets will fail, and that’s OK?
(When I was first learning Git, I was terrified of committing something that would result in a conflict. It gave me a lot of anxiety trying to avoid that from happening. Eventually I learned to just embrace that fact that sometimes you’ll have a conflict but there are ways of dealing with them.)
Creative work comes with some risks; not all experiments will succeed. Failure should always be an option, or else you stifle innovation. Organizations should tolerate some expectation of failure or they risk creating a culture where everyone tries to play it safe.
Say you have a five-day appetite for a design solution and end with having failed to find a solution. Now what?
You could:
Define a new appetite for it and try again, maybe with new resources (hire a consultant?)
Scale back and work on a smaller part of the problem, or
Switch and work on some other great idea
Maybe the project was to come up with a loyalty program, and while you explored many options the team failed to finalize a design for the program within the allotted time. So you could give yourself another week, give up and work on some other valuable idea that you feel more confident about, or scale back on the idea and maybe create a simple refer-a-friend program instead.
Without a circuit breaker there’s no safety value to force a reevaluation of how you spend your time, and nothing to prevent you from spending countless months on something–always at the expense of other value-adds you could be making–only to regret in the end having invested so much time in the damn thing.
An enlightened, well-structured design thinking process (like that advocated in “Sprint”) can certainly eliminate a lot of risk here. It’s full of great ideas, like the importance of only investing as much time in a prototype as needed to get feedback–part of what they call the “prototype mindset”:
You can prototype anything -
Prototypes are disposable - don’t’ prototype anything you aren’t willing to throw away
Build just enough to learn, but not more
The prototype must appear real - you can’t ask your customers to use their imagination, you’re got to show them something realistic to get genuine reactions
I can’t do a 260+ page book justice here, but I find it to be a valuable, easy-to-learn process for tackling big problems and testing new ideas.
Haha no fear of failure. Perfectly accepting/content with that But one of the core reasons to shape things is to improve your odds of a successful bets. Doing that shaping work to a deadline where you have to delver a potential bet at the end goes against that and I’ve found ends up increasing your odds of a bringing a bad bet to the table.
As I’ve heard Jason & Ryan (from Basecamp) say before, sometimes shaping something into a Pitch can take a day, two weeks, or maybe even a year. Not a year of constant work of course, but sometimes you can’t make progress until you’ve discovered some new information or get random inspiration in the bathtub. I agree that it’s not about spending forever shaping the perfect solution, it’s about coming up with the “good enough” solution that you’re happy with. However, the deadline often means delivery the best you could come up with in the timeframe, but that might not be good enough. Again, I’m talking about this in regards to Shaping, not Building where this things apply a little differently.
To me, it feels to me like you’re applying a lot of these thinking’s to all the stages of Shape Up. But to me, a lot of what you’ve mentioned relates more to Betting and Building stages, not when Shaping. I think the key difference being commitment.
Once something is past the Betting stage and is in Building, there’s commitment to the bet - success or failure. But Shaping doesn’t have a commitment yet. So things like circuit breaker doesn’t apply. If you find it helpful to have some kind of commitment applied to your shaping and use things like the circuit breaker to focus yourself, then that’s great and keep doing it. For me though, I like the lack of commitment during the Shaping stage. I haven’t had any issues with focus or knowing when to walk away from something and move onto something else, but I can see how others might, so that’s fair.
That’s true, it’s not even an unsaid expectation. It’s clearly an expectation (although failure should always be an option).
Sure, that’s what I’m saying. Take a wider view of what you could “Build”. Ultimately, betting is about prioritization. It’s about committing resources to problem solving. The deliverable could be all kinds of things: deploying a feature, a new design for a home page, a tutorial video, a data-model design, a hiring process, or a design for a loyalty program.
If usability research is important, why leave it to chance? Place some bets to make it happen.
Basecamp leaves things to chance…as you say, shaping up could go on for weeks or months or all year, as someone is waiting for that random inspiration in the bathtub that never comes.
There are better ways to solve big problems (such as the design thinking process spelled out in “Sprint” book.)
Basecamp doesn’t have Product Managers. They just depend on the team figuring out what to pitch and build. But that hasn’t worked very well. In recent years they went from being a leader in the cloud-based product management market to being left behind by compelling competition.
As you say, pitches could take months or years to develop. But what if your CEO or Product Manager wants to make something a priority because it’s strategically important? She wants a refer-a-friend program to incentivize word-of-mouth growth. She has some rough ideas, but she doesn’t have it all worked out, she wants the team to figure that out. So the Pitch is “design a refer-a-friend program” and the appetite is set. Sure, you might fail, as with any bet, but you should at least try to design the best refer-a-friend program you’re capable of within the allotted time. Perhaps make a minimal design for safety, then use the rest of the time to experiment and innovate additional solutions.
You could take a similar timeboxed approach to “usability testing”: run the idea by a few customers in short, to-the-point sessions to generate some useful feedback (see: “The Mom Test”). Then use the rest of the time to talk to more people or to go deeper with more time and resource-intensive sessions.
You could just hope and pray that the team will come up with great ideas for future betting tables, or you can manage the “R&D” progress by defining strategic objectives for the shaping up activity instead of leaving things to happenstance.
Sorry Max, but I’m having a hard time following your logic, as you’re kinda jumping all over the place between shaping & building stages. A lot of what you’re saying makes sense in one stage but not for the other, I’m also not sure when exactly usability testing is happening in your workflow. Would you typically look to do this while shaping a potential solution or to test the usability of the solution a team has been building?
You’re right, but I don’t see what this has to do with usability testing, which is not about strategic objectives or even solving problems, specifically. Usability testing is about checking the usability of a solution, not coming up with or validating the solution itself. It’s possible we view usability testing’s purpose differently and are therefore debating two different ideas.
The reason I don’t think a timboxed approach for usability testing is right is the same reason in the book Ryan said Shape Up likely cannot work when you need to depend on work from clients or 3rd party developers. You don’t have control over a resource you have a dependency on. What if you cannot get a decent enough sample size for your usability testing in the timeboxed time? If you have easy access to testers for this kind of stuff and that isn’t a concern, then go for it. But many business don’t have that, so timeboxing the exercise simply cannot realistically work (at least not consistently).
I also don’t agree with your premise that Basecamp is being left behind by the competition. I think their approach has worked just fine for them, considering their own objectives (which may be different from the objectives you would be setting if it was your company). Also many of the features you mention their competition having that they don’t are things I don’t actually care about those products doing it and wouldn’t need to use anyway; so Basecamp not having them isn’t an issue for me (and many others, it seems). But that’s me, and completely understandable that it doesn’t work for your needs. To each their own
OK sorry if I’m not being more clear. Maybe best if I stick to one specific concrete example for you. Let’s talk about usability testing.
I don’t understand why usability testing is different from any other activity. You don’t control all your resources; you manage and direct them. People get sick; machines breakdown. Every endeavor comes with some risks: your computers might get infected with malware which sets back your work, your developers might encounter unanticipated rabbitholes which wastes valuable days, you’re CI provider might experience downtime blocking your productivity, your designer might get sick or take bereavement leave. GIthub might face DDOS attacks from China. You can’t really plan for every contingency. Pretty much all creative work (engineering, designing, copywriting) comes with some degree of risk. It’s not like manufacturing widgets or laying bricks right?
So just like anything else you make some estimates based on experience and plan accordingly. If my fulfillment department needs 5 new laser printers, do I say, “that could take forever there’s no guarantee that they will ever arrive. I might order from one company and they go bankrupt before they ship. I might order from another company and the delivery truck could drive off a bridge. Sorry, I can’t commit to any schedule.” Of course not! Based on past experience you can say something like, “there’s a 50% chance I can get them by Tuesday and a 80% chance I can get them by Friday. So let’s say it’ll take about a week. If it’s absolutely mission critical we have 5 printers by Friday, I’ll over order from multiple vendors and we’ll deal with returning the ones we don’t need.”
You mention sample sizes but as we already established you can get useful results from just a handful of people if you have a good approach. As you wrote earlier, you generally “only speak to 8-10 people max.” So do you typically need 2 days to talk to several people, 2 weeks, or 2 months? By not scheduling this work you leaving things to chance. How long do you wait for this to happen on its own? 6 months? Two years?
What if someone on your team really hates talking to customers and never makes reaching out to them a priority? By not timeboxing it you’re virtually guaranteeing it’s not going to happen efficiently. Timeboxing the problem forces you to get creative.
We have a pretty big user base and I can get 5 people lined up in very short notice. Usually, if we reach out to them today, we can schedule them for tomorrow, or worse case it would take a few days. But maybe you have a smaller user base and they generally don’t like to participate in such usability testing sessions.
You said many businesses don’t have easy access to testers. Why is that? What can be done about it? It sounds like this is what the team needs to focus on.
“The impediment to action advances action. What stands in the way becomes the way.”
–Marcus Aurelius
One thing you can do is to build a pool of testers in advance. Send out an email periodically asking for volunteers willing to participate in a 30-minute video chat. Make it engaging by turning it into some exclusive benefit: brand it as an Early Adopters program and sell it as giving users a chance to shape the future of your product. Send volunteers some swag. If you don’t get much traction with your user community use an incentive like a $25 gift Amazon certificate. Make your usability sessions fun, so that users are likely to join one again in the future. At the end of your session, ask each user if there is anyone else you should talk to.
Do you also believe recruiting is something that can’t be timeboxed because you don’t have control over who applies? But despite those dependencies companies can and do recruit according to schedules. I could share ideas on how that’s possible, but I should stop jumping all over the place
I hope that’s useful to you, Aylon!
If you’re still confused, I highly recommend that “Sprint” book. Designers face problems they don’t have solutions for all the time. If I asked you to design a new hairdryer or a new MRI machine you might throw up your hands and give up saying, “I can’t. I’ve never designed a hairdryer before.” But an industrial designer would say, “OK. I’ve never designed a hairdryer before but I have a structured process for dealing with big problems. It’s called design thinking.”
I’m not confused by what you’re saying, and there’s a lot of truth to most of it. I just don’t agree with it when it comes to usability testing haha. I also don’t think of conducting usability tests as creative work; coming up with them yes, but not conducting them. To me, it is a lot like laying bricks lol. In order to get value you need to speak with a certain sample size or lay ‘x’ bricks (whatever the number) and you either do or don’t. Creative work, like designing/building solutions is less binary and there’s a lot of space between failure and perfection where you still have value. I.e success in creative work can be more granular than non-creative work. Again, our opinions on what usability testing is may differ here.
Moving away from deadlines for a bit, if you’re able to test the usability on your solution during your shaping efforts, I’d suggest that you may be shaping something too concrete (wrong level of abstraction). However, if your usability testing is done during the building stage, which makes more sense to me, and you’re using up part of your appetite budget to do it, then that’s your choice.
Also, I’m familiar with and practice Design Thinking, as well as Sprint. Haven’t fully read it, but followed Jonathon’s work over the years. Thanks for sharing and the good discussion
