More specifically: we set an arbitrary date with our team to release a beta that included X features. We missed that date for a variety of reasons (scope creep, design issues) and are about 2 weeks delayed. No marketing dollars were lost and we didn’t mention anything to potential users on our waitlist. We just didn’t ship something when we said we would. Are there any real downsides here other than being late? On the flipside, are there any potential upsides to this? Curious to hear peoples thoughts!
Management can use it as an excuse to get rid of people if they don’t like them and it can cause a lot of stress for development teams if there is any chance they feel like the blame can be placed on them. Other than that no
Why is it worded as a “delay” when the date is known to be arbitrary?
Sorry, key context I omitted: were early stage startup trying to find PMF, so the sooner we have something in market and getting feedback, the better, plus theoretically easier for future funding to have a product in market
If there is no external impact where customers were expecting a set of features and you failed to driver then you’re in luck. Internally, you need to optimize your sprint processes. If you had scope creep, then that’s an indication that you didn’t story point very well. On the other hand, if some of your beta customers were negatively impacted, you need to do a gap analysis on what this meant. Then you need to communicate and fess up to your customers and let them know what steps you’re taking to prevent this happening in the future.
I think scope creep is a real problem. Design issues too.
I think when you put a “arbitrary deadline” - what you are really saying is - I have a x weeks appetite for getting that done. Anything more, and we have to relook at whether it is even worth it.
For example, if you think that doing something is worth 2 weeks with a team of 4 - but then after committing to working on it, the time taken goes to 4 weeks - you as the decision maker might question whether accomplishing it was really worth the 4 weeks we spent on it. The question is not about estimates - the question is whether the output is worth the input.
A lot of times, the teams working on the projects don’t understand this tradeoff; and hence try to focus on “estimates” - rather than appetite. The team might have done a great job of doing this in 4 weeks, because it might be something really hard technically; however they would have done an even better job if they had flagged it as impossible to do in 2 weeks upfront, at least with the given approach - giving the decision maker as well as the team more flexibility (should we cut scope to fit appetite? Should we try a different approach that is maybe a hack, but worth the speed? etc.
I think terminology matters a lot in these kind of discussions and providing everyone the right context to be able to make better decisions, including say pushing back on scope creep, if the same decision maker tries to introduce them.
Reference: Shape up philosophy from Basecamp.
Totally agree with what @Marco said. I’d add that it all depends what you’re optimizing for. Is it more important to (a) get it 100% right, (b) hit a release date, or (c) ship a set of features? running over a date matters less for (a) or (c) but totally does for (b). Sharing the context with your team of what you’re optimizing for helps keep clarity on when deadlines matter and when the matter less.
In my experience it’s easier to communicate in estimated ranges when dates matter less. i.e. we need to get this right, so the deadline is 2-4 weeks. (over 4 weeks implies that the output < the input.) Rather communicate what is important and why, and empower the team members to contribute accordingly.
Great advice so far! I think there is a ton of missing context so take whatever is useful.
If there are very little unknowns and you’re confident in the success of the feature/product then delays are okay if they going improve the product in a significant way. This can include onboarding improvements, improved UX, and some performance tweaks. You want to ensure you’re delivering a great product to your users. But these delays should only be a couple of extra weeks to finalize. For these projects, I like to have two dates: the target date and the launch date. The target is our internal goal for an MVP with some padding to get feedback and improve. The launch date is is our go live and should not change so trade-offs will need to be made.
If there is more ambiguity or unknowns in the product (e.g. pre-PMF products) then you need to think of each product/feature as a bet. The bigger the bet, the more unknowns and the more uncertainty. Even if you estimate four months to complete, you probably need an earlier stop-loss.
For example (and similar to what Roopesh and Roger are talking about), you should set a short-term date to reassess whether the bet is worth it. You might want to spend 3-4 weeks to explore, prototype, and determine if it’s worth the continued investment in this product or feature. This initial period should expose the challenges of the project and the accuracy of your initial estimates. If it’s still going to be four months and that’s worth the investment then continue. But if you uncover complexities that would extend the timeline to six months, you’ll need to evaluate whether if that is worth the investment or if your time and money is better spent elsewhere.
It’s okay to spend three months experimenting just to be stopped out by new learnings. This is undeniable better than spending three months building the wrong product or one that is too complex to launch within a reasonable timeframe.
Also, check out this blog post about The Time Value of Shipping, it’s worth a read.
These somewhat arbitrary launch dates are important when a team has trouble getting new features out the door. As many of the great answer above describe, the optics can looks bad. However, releasing two weeks late is better than never. The deadline forces your hand and gives a framework for descoping and putting in constraints so you can release.
I like thinking in bets because it removes the anxiety the asking for time estimates causes. This is especially when a lot of unknowns still exist on new features.
Thank you guys, this is all extremely helpful! and @Pauline that article is great! absolutely a great framework that hits the nail on the head on what we’ve been thinking about. customer expectations in our industry have gone up, so for us in a sense, it makes sense to wait to ship so that our MVP is above the bar that they’re expecting
@Carlos that article is great (and I recommend Brandon Chu’s other writing as well). The trick is not launching too early or too late. Good luck!
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.