Alternative business models: open-source, crowd funding and tokenisation

At the Cambridge Product Management Network meet-up, Liam Crilly presented the fundamental business routes for open-source project. I talked about the various flavours of crowd-funding. 

From my experiences at Fetch.ai, I proposed that open source and crowd funding are prerequisite to tokenised business models. 

I left a question with the audience: If Tim Berners-Lee came to you with the idea of a web server + client browser, would you advise him to open-source or tokenise it?

What do you think?

The slide are available on slideshare. 

Career Paths into Product Management and Product Marketing

Last week, at the joint meeting of the Cambridge Product Management Network and Cambridge Network, I shared my observations and thoughts about common (and not so common) routes that Product Managers & Product Marketers have taken to get to their current position. Céline Sharpe from FIS (formerly WorldPay) shared her practical experience.

To view the slides, please go to Career paths into product management and product marketing on SlideShare

In summary, there are three core skills that product managers / marketers need have their arms around:

• Proposition Development (eg Sales and Marketing)
• Technical Construction (ie Engineering)
• Value Realisation / Utility (eg User Experience, Implementation, Customer Support)

Given that technology innovation dominates the software industry then this is obvious. (Product Managers in the Food industry are likely to have Food Tech credentials, right??)

But there is a whole lot of other skills requires - and these are skills that can't be taught, but have to be learnt on the job:

• Human 'Savvy' (ie awareness or sensibility)
• Communication
• Trust
• Corporate 'Savvy'
• Leadership
• Project and Process Management
• Translation

See SlideShare for more details.

From Product Manager to CEO

We know that the Product Manager is sometimes labelled the CEO of the Product. It's not the best definition, in my opinion, but I have become interested in the similarities between the role of the Product Manager and that of the CEO.

Warning: As one of the founders of the Cambridge Product Management Network, I'd love to find a speaker on this topic!

What's the difference?
Gregg Johnson was a Product Manager for 10 years and moved to Product Marketing at Salesforce and then joined Invoca as CEO. He comments that "product management is a great training ground for becoming a CEO. The very nature of the PM role requires building the skills you need to be a successful executive" in this article Want to Be a Great CEO? Be a Great Product Manager First.

Here's a summary of his reasoning:

1. Create a compelling vision for your teams and company
2. Make the hard investment decisions.
3. Navigate between the 30-day and three-year levels.

I can summarise (1) & (3) as translation  - translation based on your audience: your conversation to a developer is different to that with a sales guy, which is different to that with a customer or a partner.

But even each one of those conversations has a time consideration: if you're talking to customer in pre-sales, then you want to discuss the business benefits of your current solution. If you're inviting an existing customer to participate in your beta programme, then you'll be laying your vision for the future and how your product in beta is an important building block for the future.


McKinsey in this article Product managers for the digital world list  Sundar Pichai, Satya Nadella, and Marissa Mayer as product managers and are now CEO to Google, Microsoft and (recently departed) Yahoo!

What’s more, product management is emerging as the new training ground for future tech CEOs.

McKinsey  reports that there are 3 types of 'mini-CEO' product managers in Silicon Valley:

1. Technologist
2. Generalist
3. Business-orientated

McKinsey insightfully states:

Any critic of the analogy between product managers and CEOs will point out that product managers lack direct profit-and-loss responsibilities and armies of direct reports, so it is critical for product managers with ambitions for the C-suite to move into general management to broaden their experience.

Generally true!

What a product manager does on the first day, week, month, quarter

In conjunction with Product Focus, here's an infographic outlining what a new Product Manager should do in their first 90 days.

Download the PDF from Product Focus' website.

The raw task list was created as a result of meeting of the Cambridge Product Management Network. Then together, I and Ian Lunn from Product Focus converted the task list into an useful infographic for every product manager starting their new role.

More Product Management Mistakes (from Rich Mironov)

Rich Mironov, a product management expert, lists some of the mistakes that a new product manager might make in the first 6 months. I summarise them here, but go to the article for the details:

1. Promise a new feature to a customer without running it past your team.
2. Generalize your first three customer interviews into a market segment.
3. Confuse sales calls with customer learning/research
4. Believe your own marketing/selling materials about why customers use and love your product
5. Announce that you’re "CEO of the product"
6. Tell engineers how to solve a technical problem
7. Postpone meeting your internal counterparts
8. Confuse process steps (stories, tickets, releases) with market success (renewals, revenue, customer love)

Also take a look at 'What a Product Manager does on the first day / week / month / quarter in their new role' - a session that we have run at the Cambridge Product Management Network a couple of times.

Great Questions to ask when being interviewed for a product manager position

I read this post post, 5 Questions Great Job Candidates Ask  and thought about the great questions a product manager candidate might ask their interviewer. (FWIW, this article was linked from another one, The Perfect Job Interview in 8 Simple Steps.)

1. What do you expect me to accomplish in the first 60 to 90 days?

A cracking question because this frames the deliverables in a reasonably tightframe. It also gets the interviewer to think about how practical it is to start the job:

1. What processes are in place today (ie existing deliverables / answers, processes and coherence)?
2. What is chronically missing (that you'd be expected to put in place) - and how easy is that to fix?
3. What training exists?
4. W|hat support can be anticipated from the rest of the organisation?
5. And how important does the rest of the organisation consider your position?
   
   

You might want to compare the answers that you receive with this Cambridge Product Management Session - 'What a Product Manager does on the first day / week / month / quarter in their new role' which I lead in March 2011.

2. What are the common attributes of your top performers?

This answer indicates what gets respected as individuals: flashes of inspiration, technical genius, landing whale-sized deals, customer service and support, diligence and attention to detail or slogging one's guts out??

Great candidates want to know, because

1. they want to know if they fit
2. if they do fit, they want to be a top performer.

3. What are a few things that really drive results for the company?

This sniffs out what's important for the organisation as whole. In many ways, it's better question than 2, because it indicates the organisation's current strengths and weaknesses.

4. Can you give me an example of a new product that didn't live up to expectations? And what happened next?

So, the interviewee is uncovering how are failures / sub-optimal events handled

Lots of things can be inferred here:

1. Fame or fire culture?
2. Does the company collect and use (and reuse) data? Does it know what to collect? And from whom? How frequently is this done? Is data collection / analysis a one-off event or welded into the day-to-day business?
3. Does the company learn from mistakes?

5. If the same thing (ie failed product launch) happened today, what would happen tomorrow?

I'd recommend that this question is asked after you've got the answer to the first one!
This indicates the maturity of the organisation and its recognition of the constant need for improvement.

It would be OK if the answer to question 4 and 5 are wildly different if the organisation is young or in a rapidly moving market.

Steve Jobs - the world's greatest ever product manager

Last month's excellent Cambridge Product Management Network's excellent session debated Steve Jobs - the world's best product manager.

Clearly, I was biased as I wrote this article a year ago:
Steve Jobs - the world's greatest Product Manager and Product Marketer, shortly after SJ died.

Rob Davies proposed the motion and did an excellent job of rating Steve Jobs performance on the essential skills that a Product Manager should display.  Apple financial returns were massive - which ultimately is the only empirical measure that matters if you're developing products - see my blog post 'Apple - the most valuable company in the world'.

Elizabeth Ayer puts forward a very persuasive counter argument. She agreed that Apple's products were superb. Her key persuasive argument was that Steve Job was notorious dictator / autocrat and perfectionist. For those that have read his biography (I haven't), it is apparent that he was very difficult to work with - you definitely worked FOR him.

For this reason, I eventually disagreed with the proposition, when it came to the vote. 

SJ  created great products, but that doesn't mean he is a product manager - he didn't work in the classical definition of a product manager. Therefore he is an exception on many axes, but a classical product manager fundamentally works through others - something that Steve just didn't do.

Great debate - and definitely made me think. Thank you!

Apple - the most valuable company in the world

Apple's market capitalisation is today worth $654bn - making it the most valuable company on the stock exchange - for all time. (Technically, Microsoft had a valuation of $615 billion in December 1999 - which would, in today's money, equate to $850bn.)

Some facts (courtesy of the Economist) about Apple's dominance:

• 4.8% of the S&P 500 
• 3.7% of America’s stockmarket
• 1.3% of the global equity market.

Check this chart for its meteoric rise:

Bulls reckon that the price could go even higher—and that Apple could become the world’s first public company with a trillion-dollar market capitalisation.

No reason to doubt the optimists.

The key point is that Microsoft and Apple both generated a new and better user experience for their customers. That's how valuable UX is!

November's Cambridge Product Management Network meeting debates whether Steve Jobs was the world's greatest ever Product Manager.

Come along and join us: details here.

How to build a Product Release Checklist - expanded

On Tuesday evening, I was one of the panelists at a joint Chartered Institute of Marketing  and Cambridge Product Management Network event on Product launch disasters – and how to avoid them!

Prior to the event, I reviewed other examples of Product Release Checklists (eg New Product Launch Checklist and one of my own Checklists), then I thought that they were too specific for the product / release in mind.

So, as a Product Manager / Product Marketing Manager going through a release, you have to build you own. (Do use the examples above as reference - they aren't bad, just that you don't know their purpose!)

More useful, I thought, would be my technique for Building your own Product Release Checklist - technique that I used when I was brought in as a consultant to help deliver a release for ADP Dealer Serivces from June 2011 to March 2012

1. Determine the impact on all stakeholders

Consider how the release will impact all the stakeholders - both external (eg customers!) and internal . Some are obvious, some are more obscure and requires you, as the Product Manager to know how your company operates. See side panel for the list of (potentially) affected business functions for a B2B product release.

External Stakeholders Customers

• Front-line Users
• Customer Purchasing Decision Making Unit (technical, business, financial)

Channel Programme

• Distributors: Marketing, sales, operational teams, customer support
• Value Added Resellers: Marketing, sales, operational teams, customer support

Internal Stakeholders

• Sales
• Pre-sales
• Marketing
• Sales Operations
• Account Management
• Customer Service
• Contract / Legal team
• Installation Teams
• Finance

 2. What documents will inform stakeholders of the impact?

Imagine yourself as someone in one of these business functions listed in the side panel. What information (and at what density) will this person need in order to understand the product release and its impact on their business function.

For example:

• What product summary does an existing customer require vs a new customer
• Does the product demo need to be modified for either audience?
• Are there sub-sections of the existing customer base that will need a customised 'flavour' of the product release announcement, based their requirements? (Example: This may be necessary when not all existing customers are able to upgrade to this release.)
• What information would the Legal team require to understand the release? If there are no contract modifications required, then the Legal team would appreciate a note telling them so.

3. Build a Library of Reference Materials

As you go about your journey of discovery about a product and its release, you will amass a treasure trove of documents from internal commercial requirements to technical architecture diagrams. I recommend that you use a some sort of repository for these documents (with an index - see my example). Ideally, this should be online, so that it acts as a single repository for others to use.

Do not wait for perfection before you add any document to the repository. If the answer is 'Oh, it's the same as last time', then ask for the old version. You'll be surprised at the number of times the document from last time doesn't exist OR requires substantial revision even if it is merely freshing up the corporate branding and updating the copyright notice.

4. Build an Issues List

In collecting these documents, you will inevitably discover road blocks. Examples:

• 'Well, the product will do X or Y, based on customer Z's stated requirements, which we are waiting clarification on'. 
• 'I can't tell you the final pricing structure until person X has reviewed the operational costing for this year and next'

Note these down in the Issues List with responsibility, blocking issue and next decision date. Ideally I would recommend that you use the same tool as the document management repository because the Issues List and Document Repository are closely interrelated! Other tools that I have used are Excel and sometimes a bug management list works well too although assess to this list maybe limited),

5. Iterate!

Once you have started the document chase, you will quickly find that the Issues List far exceeds the Document Repository. The next step is to work through the Issues List allocating tasks to people and making sure that they understand that what deliverable is required of them and by when. And that you'll be nagging them (and subsequently their boss) for the deliverable.

As you may have guessed, this schedule then becomes a loose project plan for the release. In my experiences, the conflicting interdependencies within project plan (eg if we add feature X then the release will take more time and the training of the sales team will require more time). It's best not to start this project plan too early as you will be creating a rod for your back!

6. Communicate regularly

Communicate your progress on a regular basis.
With everyone

• I recommend that you have an All Hands meeting about the release. This is a great way of flushing out rumours and building enthusiasm about the product release. 
• Frequency: 2-3 months before release and the week before release date.
• With mid-management:
• This is the enabling body in any organisation - this crowd needs to be (a) onboard (b) have the ability to input their concerns and issues and (c) to be seen to be contributing in front of their peers.
• Frequency: every month or six weeks prior to release
• With execs:
• This is the decision making body. You need to schedule time with these guys to drive decision-making between their business functions and to prioritise work effort within their divisions
• Frequency: Every week or every two weeks. Book the time out now, even if you don't know how or what you are going to present!

7. Don't forget to celebrate!

Lots of effort has gone into the release - give thanks and appreciate to where it is due.

8. Conduct a Release Post Mortem

After a suitable period of time after the release, gather the stakeholders together and have an honest review of the release. What worked for each business function and what didn't?

How to build a Product Release Checklist

In review other examples of Product Release Checklists, then I thought that they were too specific for the product / release in mind.

So, as a Product Manager / Product Marketing Manager, you have to build you own.

Here's my technique for building your own Product Release Checklist:

1. Determine impact on all stakeholders
2. What documents will inform stakeholders of the impact?
3. Build a Library of Reference Materials
4. Build an Issues List
5. Iterate!
6. Communicate regularly
7. Don't forget to celebrate!

Product Management – who cares?! A VC speaks

Cambridge Product Management Network's keynote event this year will be held on Wednesday 29th June. More information at CPMN's website.

Who needs product managers anyway? Don’t they just stifle innovation? Don’t they get in the way of building stuff?

Having co-founded nCipher, a successful Cambridge IT company, and now an active entrepreneur and one of the team at Amadeus Capital, Alex van Someren has a view. Now’s your chance to hear it.

---

Alex is a General Partner in the Seed Fund at Amadeus Capital in Cambridge, UK.

Alex has worked in the technology industry since the 1980s. He co-founded ANT Ltd in 1990 to produce networking products, including Web Browser software licensed to the Oracle Corporation. ANT plc was listed on the London AIM market (AIM:ANTP) in 2005.

In 1996 he co-founded nCipher to develop internet security products using advanced cryptography. The company became a world leader in IT security, counting major banks, finance companies and governments among its customers. As CEO at nCipher he raised a total of £14m ($25m) in venture capital funding before he led the company to an IPO on the London Stock Exchange in 2000 (LSE:NCH) at a £350m valuation. nCipher plc was sold to Thales SA in 2008.

Alex lives in Cambridge, UK and is married with three children. He was appointed an Entrepreneur in Residence at the Judge Business School, University of Cambridge in 2005.

Product Manager's Playbook

CPMN
The Cambridge Product Management Network held a interactive session entitled 'What a Product Manager does on the first day / week / month / quarter in their new role' on 24th March, 2011 lead by me, Arthur Meadows.

The session was attended by Cambridge's finest and highly experienced Product Managers and together, we built a 'playbook' of recommended steps / milestones for new Product Managers as they start their new role.

The results are available here, Product Manager's Playbook. Consider this to be a Product Manager's personal project plan.

BIG Hint: This answers that age-old interview question: 'What will do if we hire you'. Also, this follows nicely on from my article 'How to hire a Product Manager'.

How to hire a product manager

Having come back to the UK from US (where Product Management is much more mature discipline), I have been saddened (and, on occasions, appalled) by the level of ignorance of non-Product Managers about Product Management.

Having seen some pretty 'shonky' job advertisements for Product Managers, I thought I'd better lay out some guidelines for everyone's benefit: How to hire a Product Manager.

Comments welcome!

Product Management in small technology companies

CPMN
Last month's Cambridge Product Management Network monthly meeting was a gem. Rob Davis gave an excellent presentation on Product Management in small technology companies (click this link to see slide deck).

What made it really interesting was that Rob distilled 10/15+ years experience in embedded software, hardware + software and purely software.

Key lessons learnt:

• Be brave
• There's more than one way to skin a cat
• Just do it

Key Influences:

• Crossing the Chasm by Geoffrey Moore
• To / Who / We Provide / That / Unlike / Our Solution Question & Answer methodology
• Getting Things Done
• PresentationZen by Garr Reynolds

An excellent 'So what' Question and Answer methodology for Product Managers to keep in their heads at all times:

• To: Description of market segment
• Who: Have a particular set of characteristics
• We Provide: Name / Description of Product
• That: Yields specific user benefit / user function
• By: My customer implementing what steps or processes and paying what money
• Unlike: Competitors' offering

Next month's presentation on Pricing should be excellent - see you there!

Agile Software Development - put in historical perspective

I went to the Cambridge Product Management Network last night on 'Product Management in the Agile World' from Roman Pichler, author of Agile Product Management with Scrum: Creating Products that Customers Love.

Agile in a historical perspective
Paul Walsh made a very insightful comment:

Agile (2000s) = Rapid Application Development (1980s) + User Experience (1990s)

RAD was all about prototyping, customer involvement and fast feedback. BUT those prototypes tended to be technology prototypes and didn't include what the customer actually received or experienced, so that they could provide decent feedback and steer the development effectively.

Paul and I nattered afterwards and both agreed that Agile wasn't best for v1 development, but much better for enhancement and product extensions.

On big, hairy feature enhancements
In fact, Agile means that you tend to avoid big, hairy feature enhancements because by their nature, they require lots of work which can't fit into a 6 week release cycle. So you tend to pick off the 'easy' incremental enhancements while the whole product slowly degrades whilst product management frets about 'biting the bullet'.

This problem is only solved by kicking out a research project that is independent of the development cycle. Agony and paralysis occurs when development needs SOME of the research project NOW and development starts cherry picking out of research. Yuk - a big management and technology sink hole, but sometimes inevitable.

Platforms
Also Agile was much harder in platform + products environment (ie products that were dependent on a platform on which other product relied upon) rather than a single product development track. I'm not saying it isn't possible, simply harder - particularly if the other products on which the platform relies have difficult development cycle times.

Thinking about it, for the same reason, products that require VAR /distribution & delivery partners mean that the feedback cycle is longer and more at arm's length than the development cycle demands. This means that there are lots of incremental releases that never make it into the market / customers' hands.

Six Rules of Product Roadmaps

Below is a presentation that I first gave to the Cambridge Product Management Network at their February 2010 meeting.

Summary:

• definition
• six rules of roadmaps
• disclosure and trust

See more presentations by arthur2020 | Upload your own PowerPoint presentations

If this embed doesn't load properly, please see this presentation on authorSTREAM's site.