How or what are the processes that you do when you have to add a feature or make a new product? Like the things that you do from the beginning of finding the problem to the release of the feature.
Just wanted to know how the real stuffs work out. Just trying to learn stuffs.
Thanks in advance.
Blue ocean?, read Sprint. I’ve seen some Sprint hate here, but I think it’s got a lot of good ideas.
Existing business? Talk to your customers, than talk to your customers some more, than use your product like a customer would. Then talk to your customers some more.
All solid product creation starts with a user and a problem.
It sounds like you’re asking for a lot and need to research this yourself.
A new product?..
I’m sure I missed a bunch, so I’m slightly curious to know how close I am from the feedback!
Pretty solid answer here!
But, in the real world (especially at big orgs) it’s on a spectrum somewhere between the above and…
I came across such a process here, you might want to take a look.
I hope it’s helpful.
@MichaelYoffe, That was really a very descriptive and useful post. Thank you so much for taking the time to post it.
@NathanEndicott, Hahaha, you’re right to quite some extent and it was funny too. Thanks for your insight.
@FelipeRibeiro, This is a great post and just what I or any newcomer like me would want to read and learn. Thanks a ton for sharing the link. Really appreciate.
Some super cool replies from @Michael and @Nathan. I would like to add here.
For a big enough new feature, I usually create a Miro board and lay out:
And then go through that with my team and have a brainstorm session for solutions. People tend to solutionize very quick though so it’s important they understand the above before doing that. I always need to reel them back in.
And then we’ll build a user flow, have some wireframes, do user testing on the designs if possible, and then build & get feedback post-launch. In a nutshell.
@DaveKim, Thank you for asking this! I had the exact same question. It’s easy to take online courses and learn all of the concepts, but hard to piece together the firehose of info you learn into a real-life situation.
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.
Continuous Discovery is how I like to work, but the boss’s-big-idea-on-the-toilet method seems to be preferred at a surprising number of companies.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.