You can't just write a "Framework", so can you just write a "Product"?Lots of frameworks exist that look great, until you start using them. Soon you find the model the author has in their head doesn't match the reality you are facing, and the impedance mismatch leads to confusing work around and 'cludges'.
The right approach...Write your app. Keep concerned separated so you make a conscious decision with each piece of code "Is this part of my domain? Is this extending the language? Is this just integration code?". Build your language so your domain code is clear and expressive. (As a hint... any code that uses Generics should be extending your programming language, not your domain.)
Then when you are done... write another app that's similar. When doing this you will copy the bits that worked from the last one, and throw away the things that didn't work out.
Then you do it again!
Eventually you have a toolkit of things that you keep copying from project to project. That's your framework. It makes design compromises in the places that don't matter to remain flexible in all the places that do matter. For each product you can use the bits you need and discard the rest.
That's why frameworks frequently come out of consulting companies. Consultants work with lots of companies solving problems in different domains, but hitting the same technical problems over and over. "Man we did this in the last project, do we really have to do it again?". Frameworks should solve these incidental problems so you can focus on the core domain.
What does this have to do with Products?When developing a product you face the same problems. You solution may miss the point, or solve half a problem, or only work for 80% of the problem and make the rest impossible.
How do you build a product that completely solves a customer's problem? Not just work well enough that customer can be sold into buying it, but well enough that customers will go crazy for it. Gush to their friends about it. Bite your hand off if you try to take it away from them!
Feel the pain.Pick a potential customer with a problem who is feeling enough pain that they will let you work alongside them in the hope you can help. If this customer is exemplar there should be lots of other potential customers should you provide enough value. Now embed yourself in their world until you too feel the pain.
Now solve a problem.Pick a problem. Start small. Quick win. Runs on the board. Low hanging fruit. You get the point.
Then pick the next problem. Solve it. Repeat.
When you solve it.. truly solve it... don't stop until you see delight in the eyes of the user. When a problem is truly solved the pain goes away.
Sure, your customer will love you, but that's not the goal. You are building your understanding of the problems in their domain. Do this long enough and you will either solve a problem big enough that it changes how your customer works. If not, find another customer to help.
If you provide enough value, your customer will rave about you! Now point your raving advocate at as many people in their industry as you can.