How We Work #2: "Some Version"

  Рет қаралды 8,342

Getting Real

Getting Real

Күн бұрын

In the second chapter, Ryan Singer, Basecamp's head of Product Strategy, explains how we fix time ("6 weeks max"), but flex scope ("there's some version of this we can get done in 6 weeks or less"), in order to repeatedly deliver great software over time. A key requirement to make this work? Autonomous teams with the power to make their own choices as they go.

Пікірлер: 11
@selvermaric4378
@selvermaric4378 6 жыл бұрын
I like this "variable scope - fixed budget" concept. Eye opener. Keep doing this video's, they are brilliant.
@DeepanManoharan01
@DeepanManoharan01 6 жыл бұрын
Very insightful and thanks a lot for sharing the wisdom.
@Stevoo84
@Stevoo84 6 жыл бұрын
Cannot wait for next episode :)
@pedroaquino5496
@pedroaquino5496 6 жыл бұрын
I love the concept of variable scope. But doesn't that generate frustration on the steakholders of the project? How to communicate with others in the company that the project was trimmed down? Is that done in the end of the project or everytime the feature changes scope, everyone interested but not directly working on the project is informed?
@moore14
@moore14 6 жыл бұрын
Would there be any set documentation that would need to come out of the 'some version', In order for there to be an understanding of how it is built and the limitations, impact it would have on other areas within the software?
@okdan
@okdan 6 жыл бұрын
When you shape the "concept" that will be handed to the team that will ultimately do the work, what does the content of that look like? Is it more goals (metrics, outcomes), or is it execution (features, UI ideas)?
@feltpresence
@feltpresence 6 жыл бұрын
Good question. We tend to take a different point of view and this could be interesting to describe. In the product work, we never set a goal in terms of some metric or measurable outcome. That is, we don't say "30% of customers should use To-Do Groups after we launch the" or "customers who use groups should have x% higher LTV" or anything like that. The concept itself is about problem/solution, and it's always described from the point of view of a single user trying to do something. Eg "We've understood that a majority of customers asking for a calendar are trying to allocate a resource and find blank spaces. Suppose you try to do that today in Basecamp's agenda view. You're looking for who's available on Tuesday the 18th, but you can't see Tuesday on the list unless there's already a date there. Here's our idea for how to solve this. [Sketches with commentary...]." We do have some expectations about whether or not a feature will impact 1% of customers or 30%, or whether we hope for a feature to impact conversion etc. But those considerations belong to the budgeting process. That is, what's worth doing right now? Whether or not that turns out to be a good bet will become evident after the work is shipped. So it's not really relevant to the in-cycle work. Generally speaking we enjoy and encourage a driver's-seat point of view for all the in-cycle work: concept definition, design decisions and review. That is, identify yourself with the situation the user is in when the problem/opportunity arises and solve for that. All the benefits we hope for in terms of measurable outcomes at an ensemble level are downstream from whether we picked the right problem to solve and whether we execute it well.
@okdan
@okdan 6 жыл бұрын
Wow - this is helpful. Thanks so much for the extended clarity in your reply. I'm excited to follow along with the videos to come. The concept of a driver's seat view is helpful. I think I was mentally conflating "in cycle" work with the budgeting process. Wherein the budgeting process is much higher up the chain. I'm trying to form my own mental model and process for how we/I do work and the basecamp approach has always been compelling.
@xpcoffee
@xpcoffee 6 жыл бұрын
Hmm - variable scope. So that has some risk: a team could change the scope to allow them to deliver in 6 weeks, but ends up making something that end users don't actually want. How do you determine if a project was successful/not?
@CourtneyStarr
@CourtneyStarr 6 жыл бұрын
Make these 2-5 minutes and I’ll watch them 🙏
@tonyhenrich6766
@tonyhenrich6766 6 жыл бұрын
No. Don't force such restrictions on others!! We want good information and I don't care how long it is. If you don't have the time to watch, don't watch. Or cut the videos into 5 minute bites or pause the video and resume the video whenever you have time. I hate these kinds of limiting suggestions.
How We Work #3: "Deliberate Allocation"
9:55
Getting Real
Рет қаралды 6 М.
Design Decisions #4: Reviewing a big feature at length
58:36
Getting Real
Рет қаралды 7 М.
На ЭТО можно смотреть БЕСКОНЕЧНО 👌👌👌
01:00
БЕЗУМНЫЙ СПОРТ
Рет қаралды 4,4 МЛН
Шаурма с сюрпризом
00:16
Новостной Гусь
Рет қаралды 6 МЛН
哈莉奎因被吓到了#Cosplay
00:20
佐助与鸣人
Рет қаралды 32 МЛН
How We Work #1: "Expect to be Done"
11:24
Getting Real
Рет қаралды 24 М.
How We Work #4: "Knowns vs. Unknowns"
12:24
Getting Real
Рет қаралды 10 М.
Design Decisions #1: Inviting people (before and after)
15:16
Getting Real
Рет қаралды 12 М.
What if all the world's biggest problems have the same solution?
24:52
I Spent 100 Hours Inside The Pyramids!
21:43
MrBeast
Рет қаралды 78 МЛН
How We Work #5: "The Hill Chart"
22:18
Getting Real
Рет қаралды 12 М.
The Rust Survival Guide
12:34
Let's Get Rusty
Рет қаралды 182 М.
На ЭТО можно смотреть БЕСКОНЕЧНО 👌👌👌
01:00
БЕЗУМНЫЙ СПОРТ
Рет қаралды 4,4 МЛН