Process for creating a new product or adding a feature to an existing product

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.

7 Likes

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.

7 Likes

It sounds like you’re asking for a lot and need to research this yourself.

A new product?..

  1. Identify the concept and build a loose proposal for research. Discovery on potential, competitive analysis, marketability, cost and the type of innovation this classifies for your company. There are three types of innovation, is it sustaining, incremental, or disruptive? Normally companies already have teams for innovation that include SLT (strategic leadership team), BI, UX, Dev, GSO (global security organization), IOps (information operations), finance, and PPO (Project Portfolio Office).
  2. After discovery, if it warrants prototyping, a Dev team is put together under Capex and given a budget with finance hoops to jump through for a budget envelope.
  3. Have an Experience roadmap planned out for three years in advance ro present to ELT (executive leadership team)
  4. Schedule meetings with outside portfolio teams in marketing, sales, customer support. Discuss ROI projections with BI and Sales team. Start talking to legal team on project needs, copyright, patents, legalese, etc.
  5. Start putting together an execution roadmap on project tracking platform with dependency reporting. Consult with PPO, QA, and dev management on release management and quality gates.
  6. Prep for weekly PSR (project summary reports) to ensure transparency in reporting.
  7. Start doing UX work. Confirm market, target audience, personas, user needs, existing competitors, standards of operations and expectations,. Work with BI, and marketing for product prototypes. Establish nomenclature and taxonomy.
  8. Bring in analytics team with UX and Dev to implement KPI telemetry on Northstar.
  9. Establish benchmarks and maturity scores.
  10. Start developing on the first version of the new product. Make sure UX is 2 sprint’s ahead and research is one major version ahead.
  11. Do all of this with solid documentation standards and project tracking.
  12. Pray you don’t embarrass yourself with ELT at your demo party.
  13. Stay on track with the RTE (release train engineer)

I’m sure I missed a bunch, so I’m slightly curious to know how close I am from the feedback!

6 Likes

Pretty solid answer here!

But, in the real world (especially at big orgs) it’s on a spectrum somewhere between the above and…

  1. VP has a genius idea while on the toilet
  2. Emails engineering that they should build it
  3. Engineering approaches product and let’s them know they have a high priority request coming in sideways
  4. Product wrangles idea, tries to put some level of clarity and organization around it to bring it to life
  5. Product and engineering move mountains to bring it life
  6. Day before launch, team’s excited
  7. VP has a genius idea while on the toilet…
5 Likes

I came across such a process here, you might want to take a look.
I hope it’s helpful.

4 Likes

@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:

  • Objective: what’s the point?
  • User problem you’re trying to solve
  • Context, if applicable (e.g. if you’re automating a manual process, what is the current process like)
  • How to measure success

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.

2 Likes

@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.

1 Like

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.

1 Like

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.