I might have something

At this point most startups are doing agile this and that: continuous integration/delivery, stand-ups, retrospectives, developers splitting their own stories, estimations using underwear sizes and whatnot.

We get that adaptation and small improvements are the way to go with regards to technical things but when it comes to product decisions we're still top-down.

Here are some guesses/hypotheses that I'm building on:

• Right now we're driving a car with the fuel gauge in the trunk. We stop from time to time and look at it. The measurement and tracking is siloed to the data team, PO or worse to a Release Manager.
• If planning would be more linked to tracking, in the same way writing tests is to writing code, it would be easy for teams to set and track success metrics on a more granular level (say user story). The hole development team will have an extra sense of how the environment reacts to their application changes. If we would write tests with the same frequency we look at analytics now, it would be just overhead and mostly useless.
• Since we're into analogies, an architect does the planning for a house and the builder builds. But the builder doesn't build all the walls to see if the house looks like the picture. He measures often: is it a right angle, is the height correct, are the bricks aligned, etc. This measuring habit should be in the fabric of day to day activities in a tech team and decisions should be made just like "if it hurts, do it often" in DevOps world.

This is not to say that we should just mindlessly iterate based on what the user says and does.
The FOUNDER needs to set the direction where the product is headed. He or she needs to point in the right direction, explain why and what the team is working for. But when it comes to decisions along the way, the team should decide based on the environment (users' behavior).

It's better to throw a ball in the blackness of uncertainty and see if it comes back than going right for it.