Our Children and The Digital Future – A Manifesto

Our Children And The Digital Future

[Note: Author is creator of Roo Kids App, an Instant Messaging app for children where parents have access to the contacts and always know who the kid is chatting with.]

Easing Children into Real World

As automobiles started to became a commonplace on the roads, parents started teaching their children how to cross a road. Our schools started talked about safety habits around the roads. School buses added STOP sign, so traffic could give way to a kid crossing the road.

The Digital Future

Digital future is inevitable and some argue we are already there. As the 4th Industrial Revolution rolls in, how do we ease and educate our kids into such a world?

Not Just The Parents

No, it is not the responsibility of just the parents. It is everybody’s concern. Especially those who are involved in creation of products (including startup founders who are re-inventing the world). Will it be easy for kids to step into this re-invented world? Or, will they stumble and fall prey to it?

Manifesto For Children Inclusive Digital Future

We (Startup Founders, Product Managers, Product Designers, Product Business Managers, Technologist) are developing products and helping others do it while keeping children in mind.

Through this work we have come to value:

  • Products that provide an overlap of safety oversight & digital access over products that are command-control tools or promote digital ignorance

[Rather than building products that isolate tech or isolate kids, we will build products that 1/ expose enough for kids to learn & explore and 2/ provide tools to provide sufficient oversight to maintain safety.]

  • Products that consider incidental or accidental use by children over products that assume otherwise

[Never assume that a child will not incidentally or accidentally access our product. Have we considered that in our design, implementation and usage guidelines? Responsibility towards children is not restricted to products created for children.]

  • Products that respect individuality, intelligence and privacy of a child over products that make stereotypic generalization like age ranges, gender, etc.

[Standardization makes sense when we can’t customize at scale. Digital products allow for customization and personalization at large scale. Digital products should adapt to a child and present a match but without violation of privacy and then providing for sufficient anonymity. Privacy also includes providing children enough space where they are assured privacy in context of parents too but always within a safe space.]

That is, while there was value in the items on the right in early days of digital evolution, we value the items on the left more.

Inspired by the Manifesto for Agile Software Development and Roo Kids App. Picture Credit: Wikimedia.org.

Manifesto For Children Inclusive Digital Future. We are developing products and helping others do it while keeping children in mind. Through this work we have come to value: Products that provide an overlap of safety oversight & digital access over products that are command-control tools or promote digital ignorance, Products that consider incidental or accidental use by children over products that assume otherwise, Products that respect individuality, intelligence and privacy of a child over products that make stereotypic generalization like age ranges, gender, etc. That is, while there was value in the items on the right in early days of digital evolution, we value the items on the left more. Inspired by the Manifesto for Agile Software Development and Roo Kids App.

Competition Analysis in 3 Simple Steps

Article on Competition Analysis

Want to get with Competition Analysis in 3 Simple Steps? Yes, only 3 🙂

Step 1: Being Competitive Means?

What does it mean to be competitive? What is the purpose of competition? And finally, when all does it mean to compete? Every business needs to be clear on these questions.

I have used this very often with the client to get them to focus on right competition and the expected outcome of being competitive:

Competitive Advantage

Step 2: Listing Competition

Competitive landscape is a spectrum. Not all competition is a threat. We need to list our potentials across the whole spectrum. I have used following 4 heading to help clients list out competition.

Competition Analysis Spectrum

Step 3. Competition Deep Dive

Identify key competition(s) from each block and do a deep dive. Here is one canvas to help structure it:

Competition Analysis Canvas

Conclusion

To revisit some thoughts:

  1. Be clear why business need to be competitive and expected outcome
  2. Competitive lanscape is a spectrum
  3. Not all competition is a threat (at a given point)
  4. Identify competitions from each block on the spectrum and do a deep dive

Shuhari – Learn – Digress – Transcend

Shuhari Learn - Digress Tanscend

Shuhari roughly translates to “first learn, then detach, and finally transcend.”

Yesterday November 26th I attended Converge Bangalore. It was a great event. Check out tweets with hashtag #ConvergeBangalore. This talk covered various ways we stay ahead to create solutions whose needs are just coming above the horizons.

I started off with talking how your software is NOT the product. However, when we put the Software in a context of  a Problem / Opportunity, identify / establish a Ecosystem, find a Product – Market Fit, identify the Early Adopters, Value Prop for Early Adopters and decide on the Success / Failure Metrics. Adding to this are Services that enable Adoption, Usability and the Ecosystem. This is when software takes form of a Product / Solution.

I often put is as:

Solution = (Software + Service) * Context

Shuhari

The talked about concept of Shu-ha-ri (Learn – Digress – Transcend) and linked it to the evolution of creating software to solution and propose what the next step will be.

Shu / Learn

  • Imbibe Rules
  • Follow Practices
  • Understand
  • Underlying Principles

Ha / Digress

  • Understand Vision
  • Bend Rules
  • Question
  • Underlying Principles

Ri / Transcend

  • Upgrade Vision
  • New Rules
  • New
  • Underlying Principles

Evolution of Product

While the day talked about moving from Software to Solution, I proposed that Solution was a Ha / Digress of Software. To Ri / Transcend, we should move to Working Business Model. This is the ultimate state of a software.

While Solution is beneficial for a client/customer, a Working Business Model is beneficial for the organization itself. Only a organization that can sustain itself can continue to provide solution.

Misc

SpeakerDeck: Shuhari – Learn – Digress – Transcend

SlideShare: Shuhari – Learn – Digress – Transcend

YouTube: https://www.youtube.com/embed/IIUqtds1G1w

Know more about Shuhari: ShuHaRi Japanese Learning System – Makigami Info

Also comments by Martin Fowler’s comments on Shuhari and this book: Agile Software Development: Alistair Cockburn

Product Development – A Primer for CxOs

Product Development Primer CxOs Cover

Product development thrives in an organization geared for Product Thinking. Else, the product development becomes a project governed by schedules & resource management, rather than being governed by MVPs, Product Backlog and Value delivered. Steven Sinofsky talks about impact of organization structures on Product in this blog. This Product Thinking must be adopted at all levels, including CxO. This is different than being hands-on with Product Development (which in itself is a topic of discussion). Role of a Product Manager (different than a Product Owner) becomes important and this article by Josh Elman is the right starting point for anyone wanting to understand Product Management.

Effective Product Development

Product Managers (ProMa) are the keepers of the vision and are expected to keep the developers, support, operations, marketing, sales, people champions and recruitment true to vision. This is a large responsibility and often leads to personal time management crunch & lots of meetings. Brandon Chu blogs about applying right leverage as ProMa is an inspirational piece on what to focus on.

Product Thinking

As organisations move from being IT to a Product Organization, one this they need to bring in is the Product Mindset, they need to manage the change very well. Seeing Products as way to deliver value to customers rather than a item of sale can help management with product thinking. Thinking of a Product as a whole entity like psychologist may do with a human and not as sub-systems and codes like a surgeon may see a human, does help developers and project managers start on path of Product Thinking.

Product Development How-To

Product Development is a well researched flow with some well documented methodologies. And of course, there is always room for dissatisfaction that precedes any innovation. While on methodologies, Marek Kirejczyk talks aboutHype Driven Development (everyone loves that latest hyped up tech/tools) and how to move away from it. There are many articles geared towards CxO on latest tech hype. Like this Insights article by Jim Highsmith and Neal Ford onMicroservices. by This 4-part Illustrated Guide to Product Development by Ben Einstein is a must see!

Thanks

With inputs from fellow ThoughtWorkers, Kartik Kannan, Kartik Rajan, Ramani Siva Prakash and Sachin Sapre.


Product Backlog

product-backlog-feature

I propose a method to build a Product Backlog, how to record a feature that has business value clearly quantified and how this fits into a project inception.

Introduction

Backlog Definition From Agile Alliance:

A backlog is a list of features or technical tasks which the team maintains and which, at a given moment, are known to be necessary and sufficient to complete a project or a release:

  • if an item on the backlog does not contribute to the project’s goal, it should be removed;
  • on the other hand, if at any time a task or feature becomes known that is considered necessary to the project, it should be added to the backlog.

These “necessary and sufficient” properties are assessed relative to the team’s state of knowledge at a particular moment; the backlog is expected to change throughout the project’s duration as the team gains knowledge.

The backlog is the primary point of entry for knowledge about requirements, and the single authoritative source defining the work to be done.

Not That Backlog

Various terms exist for a backlog being used in Agile development. Based on scope / tradition, terms Story Backlog, Feature Backlog, Epics Backlog, Development Backlog and at times Product Backlog too are used.

I will refer to these as Story Backlog so I can differentiate it with the Product backlog I am introducing in this write-up.

Story Backlog Definition From Mountain Goat Software:

The agile story backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. A typical Scrum backlog comprises the following different types of items:

  • Features
  • Bugs
  • Technical work
  • Knowledge acquisition

Story Backlog Definition From Atlassian:

A story backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The most important items are shown at the top of the story backlog so the team knows what to deliver first. The development team doesn’t work through the backlog at the product owner’s pace and the product owner isn’t pushing work to the development team. Instead, the development team pulls work from the story backlog as there is capacity for it, either continually (kanban) or by iteration (scrum).

Product Backlog

A Product Backlog is prioritized features list, containing short descriptions of all functionality desired in the product, with a business value for each feature clearly quantified along with source of the feature request / inspiration.

Product Backlog Card

A take at what a Product Card can look like:

ID
Theme / Module
Action – Expected Result / I want to – So That / Feature / Inception time Epic
Assumptions
Priority
Value Ranking
Success Metric (to judge value delivered)
Failure Metric (to trigger a re-learn / re-analyze)
Status
Source

I am still not sure if Priority would still make sense given that Value Ranking is there. The reason I have added it is because Priority represents the perspective on person who is creating this card and Value Ranking is a quantitative analysis based on weightage. Value Ranking is a kind of check on the ‘gut feel’ or ’emotional’ Priority.

I think Source is important. We should link back to the CRM entry, the social media post, a market study, email, etc that lead to creation of this. It is important to refer to that original content which can be referred to as-is in future and considered as ‘interpretation free’ source which a ProMa used.

Scoping Product Backlog Card

How much work is a feature? There are some questions that a ProMa should ask to give BAs, IMs, Dev a good idea of breadth of work involved. There is, always, more to a feature than just implementation. Look at the suggested list to get an idea what I mean here:

Time Is a GTM time identified?
If yes, date?
Collaterals Does it need marketing collaterals?
Does it need sales collaterals?
Does it need support collaterals?
Does it need user collaterals?
Change Management Does it need change in process?
Does it need change in people & behaviour?
Does it need change in how users interact?
Does it need change in tech?
Control Does it bring in regulatory & legal aspect?
Does it bring in un-handled regulatory & legal aspect?
Does it need extra/new licenses?
Does it get covered by existing licensing model?
Security & Safety Does it need extra security focus?

A yes on any of these, will affect the scope of work and for folks other than the Devs. It is important to look beyond the functionality during implementation.

Prioritizing Product Backlog

Quantifying Product Vision

A feature can be seen to provide / contribute to one or more of following values at various levels:

  • BAU
  • Strategic
  • Competitive
  • Collaborative
  • Revenue
  • Cost

Based on the vision, these six can be given various weightage.

Eg: 1/ A product like say ‘Am-Behind App’ is playing catch up on feature parity with competition, the weightage can be:

BAU           10%
Strategic     10%
Competitive   40%
Collaborative 10%
Revenue       20%
Cost          10%

 

2/ A product like say ‘Am-Expensive App’ is focused on reducing capex, the weightage can be:

BAU           10%
Strategic     10%
Competitive    5%
Collaborative  5%
Revenue       20%
Cost          50%

 

3/ A product like say ‘Want-2-Breakfree App’ is focused on growing by usual and innovative methods, the weightage can be:

BAU           25%
Strategic     30%
Competitive   40%
Collaborative  0%
Revenue        5%
Cost           0%

 

and so on. This given a quantitative representation to your product’s vision. This should not change too often. Changes to it will change the ‘value rank’ of a feature as we will see below.

However, it is expected to change given the Build-Measure-Learn nature of ProMa. The change will drive a new priority against which the Product Backlog can be re-prioritized.

Quantifying Value

Starting with asking some key questions around these vision directions.

BAU Does it address key market?
Does it add to the USP/ Key Value Prop
Strategic Does it open up new market / opportunity?
Does it offer significant competitive advantage?
Are early adopters identified?
Competitive Does it allow us to catch up with specific competition (eg: feature parity)?
Does it allow a ‘we-too-have-it’ comparison against specific competition?
Collaborative Does it help “free to use” ecosystem?
Does it help “paying to use” ecosystem?
Cost Does it bring cost benefit?
Revenue Does it enable potential revenue uplift?
Does it lead to revenue uplift indirectly?
Does it lead to revenue uplift directly?

The answers can be Yes or No and quantified as 1 or 0. A Yes will lead to a value of 1 * weightage. We can add up all the values and arrive at a value rank.

Eg: For the product ‘Want-2-Breakfree App’, a feature has been requested that allows it to address a similar need but in different domain. With this vision weightage:

BAU           25%
Strategic     30%
Competitive   40%
Collaborative  0%
Revenue        5%
Cost           0%

 

This is how feature analysis and value rank can look like:

BAU Does it address key market? Yes 25
Does it add to the USP/ Key Value Prop Yes 25
Strategic Does it open up new market / opportunity? No 0
Does it offer significant competitive advantage? Yes 30
Are early adopters identified? Yes 30
Competitive Does it allow us to catch up with specific competition (eg: feature parity)? Yes 40
Does it allow a ‘we-too-have-it’ comparison against specific competition? No 0
Collaborative Does it help “free to use” ecosystem? No 0
Does it help “paying to use” ecosystem? No 0
Cost Does it bring cost benefit? Yes 5
Revenue Does it enable potential revenue uplift? No 0
Does it lead to revenue uplift indirectly? Yes 0
Does it lead to revenue uplift directly? No 0
155

Now let us see for another feature. A feature has been requested that allows it to analyze the response via various marketing channels. This is how feature analysis and value rank can look like:

BAU Does it address key market? Yes 25
Does it add to the USP/ Key Value Prop Yes 25
Strategic Does it open up new market / opportunity? Yes 30
Does it offer significant competitive advantage? Yes 30
Are early adopters identified? Yes 30
Competitive Does it allow us to catch up with specific competition (eg: feature parity)? Yes 40
Does it allow a ‘we-too-have-it’ comparison against specific competition? No 0
Collaborative Does it help “free to use” ecosystem? No 0
Does it help “paying to use” ecosystem? No 0
Cost Does it bring cost benefit? Yes 5
Revenue Does it enable potential revenue uplift? Yes 0
Does it lead to revenue uplift indirectly? Yes 0
Does it lead to revenue uplift directly? No 0
185

So, the later feature should be prioritized higher in the Product Backlog.

Product Backlog and Inceptions

How does a Product Backlog fit into our Inception? Here is my earlier blog post on this: Product Management During Project Inception

Summary:

product-management-role-project-inception-feature
Product Management Role in Project Inception Feature

Never Alone

This started with a lunch time discussion with Sriram Narayan few months back. It got re-triggered by a question by Kartik Kannan “How do ProMa figure in Inception Process?” Thanks to Priyanka Kapur and Anantpal Singh Saluja who became first user of this method while creating a pitch for a client.