This is basically from Teresa Torres’ continuous discovery habits - but I think it really has worked in practice (better in truly product-led orgs with good culture, which aren’t extremely common). As I’m in an early stage startup right now and leading product it’s been easier to implement this than other areas.
This is more focused on not necessarily a new product or a gtm strategy, but prioritizing opportunities. What you’ll see at most companies is - they prioritize solutions more than problems - and do some simple “discovery” (more or less just testing) to make sure the chosen solution is going to be successful.
The more ideal framework requires you have a strong company roadmap and product vision at a high level and leadership chooses KPIs that are indicative of success in getting to their objectives. Then they in collaboration with the product org choose corresponding “product outcomes” (Torres) or “optimization levers” (Amazon) that will most drive these company level KPIs and actually represent delivered value to customers.
For simplicity this could look like $ revenue target → Conversion rates → the amount of xyz activities new signups do during a trial period.
When teams have been given a product outcome they feel actual control and input over they can work to identify the opportunities branching from this that are most likely to influence that metric. Torres defines opportunities as Unmet needs, pains, or desires of customers/users. This can be applied at many different company sizes. For duolingo addressing Churn of new users, a problem could be users not feeling successful in their first few days of activity or users wanting to use the language in a real setting with a real person after learning it or users needing a forum/community to discuss language learning with.
After identifying opportunities you validate (talk to users, check your data, talk with stakeholders, use frameworks, etc) and prioritize them. — the honest truth is validation should be happening regularly enough that you don’t feel the need to validate EVERYTHING in one conversation, if it happens regularly you will just ask the questions relevant today/this week.
Then you get to brainstorming solutions, you choose your top options (realistically you might just be sold on one or two) and you start doing some low fidelity work.
I actually do experience map these with new teams quite often since it’s important to get on the same page. Then after mapping what it should structurally look and flow like, we map out our assumptions and rank them. Then we organize those high importance assumptions into ways to learn more. Then we interview, so usability tests, talk with different devs, etc. to map out the experience.
I mean a lot of this is going to sound idealistic to people, but its honestly very doable if you don’t have too much crazy process (which is unlikely in any large company). This is just one method though, people might hate PR FAQs at amazon, but working backwards has a lot of merits as well if done correctly.
Hope it’s helpful, this is by no means the most efficient or a golden standard of any sorts. Just hopefully helps with visualizing an actual project workflow. I ignored most of the delivery end of things because we’ve found great discovery makes delivery much easier and more straightforward.