There a couple of ways to approach the challenge, but (like some others have said) trying to force it into a framework that is meant for execution and measurement will just frustrate you.
Instead I recommend looking at models that are meant to complement the execution of known features. Some have described it as a "dual track" model, where you have some focused on discovering the next feature and other focused on the sprint execution of features already discovered. You can learn a little more about it in an Aaron Sanders Blog Post. Aaron co-founded CoMakers with Jeff Patton and this article dates from his time there.
The problem with the term and drawing unfortunately though are that it lets people believe they can still tie it up in a nice pretty process box, but discovery and figuring out what to do next can get messy. That is why Scrum STARTS with a backlog at the beginning. Product Discovery and UX help you get a better backlog.
Here is my version that I use to explain the concept, but it is in now way meant to represent "the way".
The main points is that you have a team that has to play different roles and work that is in different stages, but the basic idea is that ideas go through a discovery, experiment and validation process and IF validated get added to a backlog that a team can pick up in a sprint and then those feature, once delivered, should be measured or looked at for new ideas to start again. One other think to note is that the "discovery loops" are not meant to show any time or size or velocity, but they should fast, continuous and valuable.
This is hard stuff and requires a lot of dedicated people and trust, since you aren't scheduling discovery.