As a long distance track running in high school and college, and later as a Navy Deep Sea Diver (special forces), I've experienced how keeping an aggressive stride goes beyond tiring and gets you into an momentum I call "automatic mode." This is when you achieve peak performance and you can go far beyond what the mind will limit you to otherwise. The military calls this "mind over matter" and is a real phenomenon. My Mother-In-Law trained for the Olympics in swimming and calls this point of going beyond exhaustion "the wall". The key to getting into this state is to establish a strong stride and keep repeating that stride tirelessly, despite changes in surroundings. What I found in the Navy, and as I worked as a life guard on an ocean beach one summer, the stride can include how you deal with changes in your environment, changing the pace and still keep the stride. We would run in knee deep water, soft sand, hard sand, marsh grass, etc. As we moved between these conditions we would change the pace but keep the stride.
I've only experienced peak performance results a few times in software development projects, but it can be achieved. The approach is to train the team for the inevitability that we may have to turn sharply in strategy and tactics. This enables the team to operate in new directions relatively quickly without breaking stride. If you don't build the team with this inevitability in mind and train for it, the team is easily rattled and breaks stride with every change, unable to achieve peak performance and can result in productivity erosion.
Agile software development lifecycles profess that projects are broken down into time-boxed iterations with prioritized work items, and software is delivered in demonstratable or releasable condition at the end of each iteration. The iteration is the stride of the team. The team does not like to break it's stride. So, account for the 'agility' of dealing with sharp changes in project direction. Change the work (pace) but preserve the current iteration cycle (stride). By putting in place best practices for planning and communicating this change as part of a subsequent iteration, the team can embrace the sharp changes as part of the process and not a disruption.
Achieving peak performance in an early startup requires a process that is focused on iterations within a project lifecycle that embraces responses to user feedback, changes in the marketplace, business strategy, technological discoveries, and other environmental conditions that make sense to respond to quickly. While planning these changes take into account the costs to the project and the team. There are research spikes (specific time allocated to research a topic enough to plan work), architectural impact, adjusting expectations in project commitments, changes in task priorities, and human factors. It is important to acknowledge these impacts and plan accordingly.