The document discusses key aspects of building an innovative product. It outlines that innovation requires (1) focusing on problems you care about, (2) generating many ideas through close user understanding and experimentation, (3) rapidly validating ideas with analytics and user testing, (4) enabling fast and cheap experimentation through tools like DevOps, and (5) empowering a small team of people who are passionate about solving the problem. Digital solutions can now be built and distributed at low cost by small teams to reach global users, making innovation a powerful approach.

1. Building an
Innovative Product
Shishir Chandra Choudhary

2. What’s Innovation ?
1. Problem you care about
2. Idea Generation
3. Idea Validation
4. High Speed and
Low Cost of
Iteration
5. Empowered People who love
what they do and care about the problem

3. Why innovation is hot ?
• Digital solutions today scale well
• Whatsapp was built by a dozen member team and
used by billions of users
• Once a software is written it can be distributed at
marginal cost to billions of people
• Cost of research/innovation distributes well

4. 1. Problem
You care about
• Innovation is a winding path. It
is series of misses, which direct
you in right direction, before you
get a hit
• People put more effort for things
they care about and innovation
requires that extra push
• Only people who love their work
create ground breaking products

5. 2. Idea Generation
For idea generation you want to do following
• Improve quality of ideas
• Improve quantity of ideas

6. Idea Quality & Quantity
•Be cloooose to users
• Ideally - be your own target
demographic. (or else be closer to that)
The resulting depth of understanding
of the problem is unmatchable. That
is crucial in solving the problem well.
• E.g. if an investment product, be
user of that investment product to
invest. Maybe include a user in
your team full time, but still each
members should use the product
themselves as a user.
• Entire team should feel as close to
users as possible. Whole team must be
aware of user interviews, feedback and
product user behaviour analytics.

7. Idea Quality and Quantity
•Explore
• Experiment a lot (cheaply).
Each experiment improves
your next idea quality.
• Have a long term process,
with progress measured by
learning done, not success
of every step (don’t
measure innovation in
similar way as execution/
delivery projects)

8. Idea Quality and Quantity
• Be aware of and leverage
Open Source
• Don’t reinvent the wheel,
leverage open source to
solve common problems
well, contribute back to it
as well
• Be aware of what is
possible with bleeding
edge open source

9. 3. Idea Validation
• Never drive blind
Build analytics into your product
so you know how well is your
product doing? how is it being
used? Did your last improvement
improve retention or referral ? Did
the last idea deployed become
popular ?
• Talk to users who used your new
idea
• Take your product/new ideas for
test drive yourself on a new road.
Often you will notice any pain
more directly.

10. Idea Validation
Analytics
• A missing analytics piece is a
death knell for product
improvement.
• Each cycle of release should
use analytics to measure and
understand user’s response to
that change
• These iterations should become
fast with investment in devops
tools that help to rapidly take
ideas to users, possibly with A/
B testing small set of users

11. 4. Rapid Cheap
Experimentation
• If each experiment takes
months or hundred thousand
dollars to conduct , you would
not experiment much
• Invest in building infrastructure
to enable rapid
experimentation using devops
and any tool to that effect

12. 5. Empowered People
Who love their work and care about the problem
• People are very important component of
innovation
• Hire people who just love what they do.
People who do work just to pay bills never
build ground breaking products
• Empower them, trust them. Use agile
approaches where you don’t stand behind
the shoulders or try to control people.
• Agile daily stands should be just 5-10 min
of what each person is doing today and
not a question and answer or control
system. Note this requires people who
love what they do.
• Teams should be small (5-10) and self
sufficient