From Idea to Feature

Ideas are everywhere. The magic is in the Execution.

More often than not, Ideas come rushing at us from all angles and we want to internalize them, make sense of them and see them come to life. This is the hard part many PMs and founders battle and like you, I have been there many times, until I found a hack.

Yes, I will share with you.

Having personally repeated this framework’s success across 4 [totally opposite] verticals, there are high chances that if you adopt these steps, your ideas’ execution would be 5-7X better than it currently is.

Importantly, Validate Everything.

A rule of thumb is that no idea should proceed to production without being validated as solving an important problem, usable and stable.

This means – the user must enjoy value, should very quickly understand how to use it, must align with your business goals and of course it must be technically possible.

My recommended validation process is below ;

• Product Manager must be responsible for gathering feedback on all current features, as well as validating any new features being discussed.
• The Design team is responsible for building mockups in readiness for validation. Once the feature is validated, the design sprint should get them ready for development.
• Org Leaders [ CTO, CPO, HoP] keeps a close look on the balance between new features, blindsided issues, and performing necessary actions, to drive efficiency.

It is recommended to have daily stand-ups [ mornings preferably ].

Any collaboration tool of your choice will help adapt your daily, weekly and monthly workflows from idea through validation and development to ultimately shipping an elegant product for your users.

A critical component is your workflow.

Very often, I find product orgs with workflows that mimic the below ;

1. Current Development
2. Planning
3. Issues
4. Backlog

1. Current Development -

Primarily, this should be everything that helps you move things along :

a. Active Design - Validated features begin the journey here.

b. Prioritized for implementation - Your prioritized list of what engineering should work on next. Features that do not typically require any design go here directly (bugs, re-factoring etc.).

c. Active Development - Everything currently under development.

d. Testing [Unit / Integration] - When development is done, everything moves here for testing.

e. Production ready - If testing succeeds, all items goes here. [ Some startups run soft launch(es) here ]

f. Launch - I recommend you house everything that will and has gone live.

It is important to note that a lot of feedback should be shared throughout the development process, so items should naturally move back and forth between a few times before getting shipped.

Your priority should be that all actions are correctly placed. Remember, forward is not always progress.

2. Planning -

One best practice is for the Product Manager, Product Designer and [CPO/CTO] to align weekly [Midweek Preferably] on feedback gathered from users, research learnings and re-visit old product ideas that could be contextually useful currently.

This list will help you follow through that flow:

a. Potential Experiments - All your great new ideas for features begin at this stage.

b. Ongoing Experiment - The Product Manager validates [or invalidates] the features with a preselected segment of users.

c. Validated and Prioritized - If a feature gets validated, your designer is now ready to flag it as “Active Design” on Current Development.

3. Issues -

All product managers [maybe almost] want to build perfect products. The stark reality is that issues / bugs can suddenly show up. To manage this, an excellent strategy is to keep two simple lists ;

a. Inbox - This is the “dumping’ space for all issues found. I typically ensure an in-house independent engineer verifies all issues found at this stage.

b. Confirmed (Prioritized) - Once verified as something we should assign man-days to, we move this to “Current Development”.

As you might know, it is always helpful to color code incoming issues as this helps with prioritization and your teams’ phycological balance. This example below was used by my team ;

Unlabelled = Non-critical.

Purple = Look at this when you have some time.

Orange = Attend to this when you are done with current task.

Red = Leave everything and solve this right now.

4. Backlog -

Remember that the Product Manager, Product Designer and CPO/CTO meets weekly. The backlog is an important action point during this meeting.

Many times, I have found it life saving to zoom out of all that is happening and move to refactor or optimize existing code. An important action for the CPO is to introduce all items that need attention in the coming week, to ensure everything runs as smooth as possible.

Usually, the list should comprise of :

a. Frontend

b. Backend

c. Operations

An important note is to always attach tasks to people, so everyone knows who is responsible for each of the tasks and for addressing pressing issues.