Dirty-Work Group – A Model for Entrepreneurs

Dirty-Work Group

Or Don’t Let Your Lack of Ability To Do a Part-of-it Stop You from Doing What You Want to Happen

Let us face it. Either we have all the talent needed to pull off an idea or we do not have all the talent to pull off the idea. Should this lacking stop us from going ahead and follow the idea?

Conventional wisdom says, if you can’t do it, you won’t be able to do it. So forget it.

Should we?

In a modern market, a businessman should have multiple capabilities to survive. Not every entrepreneur can hire accountants, financial advisors, lawyers, technical experts for advice. They start with limited resources and consultants don’t come cheap.

All entrepreneurs have one common quality. They are good at multiple tasks. If a successful entrepreneur was good at computers, sure there was at least one more field which the entrepreneur had a “natural knack” for. Maybe marketing, finance or any other area that helped in converting an “idea” into a business reality.

But at times either that is not sufficient or there maybe a lack of “natural knack”. It can discourage an entrepreneur into inaction. A Dirty-Work Group model can be a good approach to walk away unscathed by all these problems.

The Process

As you follow the Beating Down the Idea you would have broken down your projects into activities. The thing different in this break-down is that the activities are classified as per your (the initiator’s) capabilities. It will help you understand your strengths and weaknesses. Use this list to look for a team that will make up for these lacking.

The Advantage

Besides a help in forming a team, the process is useful in:

  • Identifying the strength and weakness of team members
  • Identifying weakness that is not covered by another team member and thus identify a weak link
  • Taking the first step where the results of analysis can be directed inwards rather than outwards. Most planning and analysis tools are for “telling” others about a project. The DWG method is easy to adapt and hence greater advantage for the project itself.
  • It is a great team-work promoting method.
  • It helps the “purpose” rather than “people” become the leader and guiding principle.

More Reading

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.


Product Entrepreneurship v/s Product Management

Product Entrepreneurship

“So, Product Manager is like a Project Manager for a Product?”

“Isn’t Management all about keeping things running?”

“Do I need an MBA to be a Product Manager?”

“I don’t want to be a Manager.”

“Nobody likes Managers.”

Does term Product Management reflect the breadth, creativity and responsibility? The more I ask, the more I realize it does not.

A lot of this may be due to growing number of ‘Leader v/s Manager’ comparisons on LinkedIn and lack of clarity on difference between Project Manager and Product Manager.

Anyway, does it matter? If the colloquial meaning does not match the textbook meaning, should it concern us? Maybe yes, maybe no.

However, given the evolution of Product and how we interact with them, it is time for a reimagine. And what better way to start than to look for the right name.

Product Management

Let us look at the life of a product and how it fits into Double Diamond paradigm. For this we need to extend the paradigm. Here is what it can look like:

This is how the RACI matrix for a Product Manager is perceived to look like for each phase:

4-diamonds

Phase Opportunity Strategy Discovery Define Design Deliver Sustain Sunset
Product Manager Consulted Responsible Responsible Informed Accountable Informed

Product Entrepreneur

The role of a Product Entrepreneur can be used to describe the real breadth of the scope of work that makes a product possible.

4-diamonds

This is how the RACI matrix for a Product Entrepreneur is perceived to look like for each phase:

Phase Opportunity Strategy Discovery Define Design Deliver Sustain Sunset
Product Manager Consulted Responsible Responsible Informed Accountable Informed
Product Entrepreneur Consulted Consulted Responsible Responsible Responsible Informed Accountable Accountable

Product Entrepreneur may be a better term for the breath of work. The adoption of this may be a whole different story.

Curious about the diamonds I have used above? Read this excellent ThoughtWorks Insights blog on Double Diamond.