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?
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?
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)?
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.
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.
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?
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.
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
I like this "variable scope - fixed budget" concept. Eye opener. Keep doing this video's, they are brilliant.
Very insightful and thanks a lot for sharing the wisdom.
Cannot wait for next episode :)
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?
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?
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)?
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.
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.
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?
Make these 2-5 minutes and I’ll watch them 🙏
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.