When we talk about performance, we shouldn’t look only to performance of code execution. There are more types that we should care about, like time to market, development time and processes. Actually, we shouldn’t look into any of the performance measures at a single perspective. As I see, all these measures sums up to constitute a single value of business performance.
There are lots of things that can slow down your business, and if you have a slow business, you’ll have a hard time to keep pace with your rivals. As you discover that some areas of your company may be slowing you down, you may become tempted to add key performance indicators to each step trying to squeeze all possible value out of each part of your processes. This can bring up a whole new set of problems, your business can be seen as a complex system and it will adapt itself to render good results even in chaotic scenarios. 
So, to avoid going nuts with indicators all over the place, you decide to avoid bottlenecks from the start. To each and every new thing you need to deliver, you’ll start a precise planning routine, choosing among a plethora of providers, technologies and unicorns to avoid at all costs to have a new bottleneck in the future. This is what I like to call premature optimization in business performance.
Simply put: you can’t have a business if you don’t have a business. How can you possibly know all the events that will happen to have an impact in the decision you take today? You can’t.I’m not saying that planning is wrong or a Bad Thing™. What I really want to avoid is losing energy on stuff that won’t make a difference. You may spend a whole year choosing between apples and oranges, and in the end be crushed by some weirdo playing around with random technology. Why? Because he was not worried about future bottlenecks. He was really trying to do something cool, and he did it while you were arguing in endless and purposeless meetings.
You’re always trading performance measurements. For example, everyone is talking about service oriented architecture (SOA), but what does it really means in terms of business? It means a tradeoff between code execution performance and others benefits to the business as a whole, like decentralized grow and continuous delivery. Or, you may look at the difference between Apple’s App Store and Google’s Play Store model. There is a huge tradeoff of quality assurance and time to market between these two players: one offers their customers (smartphone owners), quality assured apps; the other offers their customers (operating system users), fast time to market for their apps.
The big question really is: what are you trying to deliver to your customer? Are you trying to deliver software over time or value over time? I bet most of you are trying to deliver value over time, so why bother with premature optimization of technologies or processes? Let the bad stuff to die on its own: failing fast is orders of magnitude better than not doing anything at all. And let the good stuff to accompany you to where you want to go.
Don’t bother guessing the future, embrace the uncertainty of life: you can’t predict how a complex system will behave, you can’t know how your systems, services or whatever you are doing will be used in the real world. Put it into the wild, take the complaints and tune it (or throw it away) afterwards, this is a constant process. 
Start measuring how much you are delivering over time and stop over-planning. Your end goal is to deliver stuff. The world couldn’t care less about what you can do, it only cares about what you do.