Thesis: In a perfect training plan (consisting of 2 base, 2 build and 1 specialty phases) progression levels (PL) would evolve roughly as follows (along with FTP increasing at the same time):
- Base 1 - PL 1-4
- Base 2 - PL 3-6
- Build 1 - PL 4-7
- Build 2 - PL 6-8
- Specialty - PL 7-10
This is because in most disciples the duration stays more or less the same so an increase in PL means higher intensity, longer intervals and less rest. These should (based on everything I have ever read or heard on the topic) get more demanding in a fairly linear fashion as the plan progresses to ensure optimal adaptations.
Issue: It is currently possible to get a training plan from the plan builder with progression levels way above what is underlined above which can result in absolutely brutal workouts right out of the gate particularly in low volume plans. I doubt that this is a sustainable road to success.
Solution: One fairly simple solution would be to implement hard coded upper limits of what PLs you can have entering a specific training phase. Counting backwards from the end to the beginning these could be for example:
- Specialty - MaxPL=9
- Build 2 - MaxPL=7
- Build 1 - MaxPL=6
- Base 2 - MaxPL=5
- Base 1 - Max PL=4
The check could simply be:
- IF PL(Athlete.Diciple) > MaxPL(Diciple.Phase) THEN PL(Athlete.Diciple) = MaxPL(Diciple.Phase)
If there would be less phases than described above, you could just omit the missing phases from the beginning.
If there would be more phases, could could extend the curve accordingly.
Within each phase PLs could move freely and if the actual PL would be below MaxPL (Diciple), nothing would change, so this would be simple one time check at the beginning of each phase (followed by a suggestion for plan adjustment, if necessary).
The simplest and least invasive way to implement (or test) this type system would be a simple opt in (YES / NO) toggle in the account settings, by default set to āNOā. If implemented this way, this feature should require minimal coding and very limited other resources and could easily be removed, if data would not support its inclusion in the product.
I understand that this would not be suitable for everyone (particularly those competing) and probably not even needed by manyt, but it might still be worth considering to to improve the product for edge cases.
Thank you for your time.