Different types of product manager: A worked example

In my last post I talked about 4 dimensions that determine what kind of product manager an organization needs:

• Number of employees in the organization
• Number of users for your product
• Nature of the product
• Culture of the organization

Different types of organization and product expect/require different types of product management. We all say “product management” but we can mean very different things when we say it, depending on where the organization and product is along these four dimensions.

Here is an example based on a real experience of mine to illustrate this. It was when I was at Rated People, probably about 2010. It shows how the decision-making around the product (i.e. the product management) was informed by these four dimensions.

Rated People is a marketplace where home-owners post jobs they need done. Each job is notified to relevant tradespeople who can then choose to bid for that job or not. The system figures out if a tradesperson is relevant based on the type of work they do (plumbing, carpentry etc) and which areas they work in.

Which areas they work in was originally set by giving a central address and a distance. The system would calculate a circle using the distance as the radius. This was problematic because it didn’t reflect the reality of where people would travel to for work. Famously, London is split into North and South parts by the river Thames. Crossing the river can be time-consuming. People on the north side are more likely to spend more time on the north side of the river and those on the south to stay on the south side more.

We had three different ideas about how to address this problem.

First approach: Pave The Cow Paths. User testing showed that tradespeople generally thought of their work areas based on postcodes. So we could have come up with a solution that would let you enter a list of postcodes somehow, either by clicking on a map or by writing them into a form.

Second approach: Use the latest tech. In 2010 we now had the ability to draw any shape on a map. This seemed quite neat but when we then put it through user testing, our users found it very frustrating to draw the shape they wanted. This feature would have been a complete non-starter for our users.

Third approach: Lateral-thinking application of new tech. This is what we ended up going with. We approximated a circle with an octagon and allowed the user to drag the corners around. This worked well because if you were happy with the auto-generated circular area, the octagon was pretty much good enough for you. If you wanted to change the area then you could pretty well draw any shape you wanted by dragging the corner points. Hat tip to the mighty Oleg Roshka who did all the heavy lifting to make this feature happen.

The Lateral-thinking application of new tech suited us at the time because of where we were against the four dimensions:

• We were a relatively small organization and so could easily get a few key people on a call together to figure out the right solution together
• We had a relatively high number of customers (10’s of thousands) who weren’t particularly tech-savvy
• We wanted this part of the product to be a differentiator compared to the competition (the tradespeople are the paying side of the marketplace)
• The founder liked relatively elegant tech solutions that generalized well

It’s not a case that the other approaches were worse. They would have been more appropriate in different circumstances. The use the latest tech could have worked if our user base was more tech-savvy, for example. Pave the cow paths could have worked but it would have needed a fair amount of fine-tuning after release because different people, in different parts of the country, needed different levels of granularity to define their work areas.

The organization valued and needed this Lateral-thinking application of new tech at the time. That doesn’t suit all products and all organizations.

Here’s an example where pave the cow paths was the right approach. It’s from no less than Facebook and their photos product in 2005:

[E]very development in the Facebook photos product can be linked to that moment in 2005 when the team saw how people were using the photos: “Instead of trying to change people’s behaviour, they codified it.”

https://www.mindtheproduct.com/paving-cow-path-and-other-stories-by-simon-cross/

Facebook started 2005 with 1 million active users and ended with 5 million. This would have meant a lot of engineering challenges around scalability and stability and/or a lot of firefighting to keep the site up and working well. Accel Partners made their $13m investment into Facebook in 2005 which would have meant a lot of hiring. Based on this, some educated guessing about how Facebook would have measured up against the four dimensions:

1. Relatively small organization but going through a lot of hiring and organizational change
2. Very large user base who were young and relatively tech-savvy
3. The product team was up against more established competitors in the photo space, and so had to find a relatively simpler way of getting more activity on Facebook photos
4. The culture was about “moving fast and breaking things”

In this context, it made a lot of sense for the user-facing side of the PM team to get to grips with user behaviour and codify it. If it didn’t work to increase user activity they could pivot to a different idea.

I’m using Facebook as an example because it’s a well-known company that was explicitly following a pave the cow paths philosophy. Please don’t fall victim to survivorship bias and assume that dropping a 2005 Facebook PM into another organization would magically fix things¹.

It’s horses for courses. Different organizations and products expect and need different things from their product managers². We make things harder for ourselves by describing this all under one job title: “product manager” when in reality we mean a lot of different things depending on the context.

With all this said, do you want to see the Rated People feature I was talking about? Of course you do, and you’re in luck because it seems this feature worked well from a user point of view: it’s still there nearly 15 years later.

Here’s an example from DJC Contractors. I’m going to imagine that they live somewhere around the L or the o of London given that they are happy to go further north-west than they are south-east.

Here’s one for Comforooms ltd who are keen on the Western side of London.

On the other hand, Light Electrics, below, works on the Eastern side of London and surrounding areas. They are happy to work in Dartford but apparently don’t want to go to Croydon or as far as Watford. So I’m going to guess they are based relatively close to Chelmsford.

Or getting away from the capital, below are Next Gen Driveways who cover the whole of the South West of England, Swansea, Cardiff and Newport but have explicitly excluded some major local cities/towns (Bristol and Bath).

1. If anything, this Facebook example is a good counterpoint to the prevailing wisdom that you should not be paving cow paths, depending on the context of the organization and the product ↩︎
2. Even in this Facebook example, I’d expect that a PM working on the advertiser side of the business would treat things differently because those are the paying customers. ↩︎

How to figure out what type of product manager an organization needs

The (software) product manager job role is far from standardized. It can mean very different things in different organizations. Check how your organization maps across four dimensions to figure out what kind of product manager it needs. And to determine if it’s the right place for you as a PM.

I used to think of product management as a linear progression. Starting from the very first days of a startup, where a founder is driving the whole product vision, to a professionalised, product-led approach.

Something like the pioneer/settler/town planner model, (with some further useful discussion on it here)

Or along the lines of this model from Gartner:

To be fair, the Pioneers/Settlers/Town Planners and the Gartner models aren’t necessarily straightforward maturity models. But they do a good job of articulating different approaches to product management.

What they don’t tell you is where on the model you should be.

I used to think it was just down to the scale of your organization. A smaller one would be more pioneering or instinct-driven, while a larger one would need to become more product-led, or risk becoming a dead-end feature factory.

It turns out that it’s more nuanced than that¹. Here are four dimensions that will help clarify what an organization needs when they say product manager:

• Number of employees in the organization
• Number of users
• Nature of the product
• Culture of the organization

There will often be correlation between these, but not always.

Number of employees in the organization

As the organization gets larger, Metcalfe’s law becomes more of a challenge: The more people you have, the number of potential touchpoints goes up exponentially.

A smaller organization is more about individuals. The stakeholder management aspect product role is more about your relationships with specific (probably highly-opinionated) individuals.

As the organization scales the stakeholder management piece becomes much more about aligning multiple stakeholders, handling cross-functional teams and removing organizational obstacles.

Number of users

A product with 10 users is going to feel very different to one with 100 which, in turn will feel very different to one with 1000 or 10,000 etc.

At 10 users, the person running product can intimately know what everyone needs, perhaps better than the users themselves. At 100, one person can still have an overview of all the users but you can start thinking about ideal customer profiles and all that good stuff. If you’re in the 10’s of thousands then user research, customer testing and user segmentation take on a whole new meaning.

Nature of the product

Let’s simplify for a moment and call the (software) product we’re creating a website. Even in this simplified scenario it’s clear that not all websites are created equal.

Assume you’re an airline. You need a website so that people can find your flights, book them, get their loyalty points, get customer support, handle changes and other problems, etc. But the website is not your product. Your product is flying people from one place to another.

Similar story if you’re a hotel or a retailer where the software product is an enabler, it’s not your real product.

Very different story if you’re selling a SaaS product. In this case your web app is your product. Similar if you’re a marketplace: for sure you need the buyers and the sellers on there but your web app is far more central to your product than in the airline or hotel or retailer example.

If you are selling your web app then the nature of the product role is more technical than if you’re not selling your web app. By “more technical” I mean that understanding the art of the possible is a much more important part of the product role than in a similar scale organization where the website because you are likely to be trying to differentiate your product from your competitors more.

Culture of the organization

Imagine an organization that wants to move fast and break things.

Now imagine an organization working in a highly-regulated environment that has a much longer time-horizon.

These will need to take a very different approach to their product management. The move fast and break things culture will prioritise getting things out to users fast. The organization with a longer time-horizon will prioritize more planning, iteration, experimentation and validation before something goes live.

This is not to say that the organization with the longer time-horizon is necessarily going to be more sleepy than the “move fast and break things” one. You can still do experiments at pace even if you’re not delivering working products live. In my experience I’ve seen some products where the users value stability and so would prefer things to know about new features weeks ahead of time, and others where users would jump on a new thing if it can be released in the next few days.

Putting it all together

Here are a few examples based on places I’ve seen.

Company A: <100 employees (more personal than cross-team); >25,000 customers (lots of user testing, user research); B2B2C marketplace (relatively technical understanding needed); Engineering-heavy culture (needed to be relatively nerdy)

Company B: >5,000 employees (lots of cross-functional alignment needed); < 10 customers (new product, so needed to differentiate); B2B SaaS product (relatively technical understanding needed); culture valued slow and steady planning with a long time horizon

Company C: <100 employees; >100 customers; Services company – tech was mainly an internal tool (so didn’t need too much technical know-how); very commercial-focussed culture focussed on building features to help win new clients

Each of these companies had very different needs in their product managers. Not to say one is better and one is worse. Just that, for example, if a Company A or B PM found themselves in Company C they might feel like they were in a feature factory. Conversely, a Company A or C PM would feel stifled in Company B.

1. Credit to an inspiring conversation with Andy Richardson, among others, at a London CTOs unconference session about the pros and cons of the CPTO title, followed up by some discussions with the ever-challenging Chirag Shah. ↩︎

Bonfire of the Best Practices

As we get stuck into 2024 I am wondering how many of the product and engineering best practices that we’ve seen develop over the past 10-15 years will turn out to be ZIRPs (“zero interest rate phenomenon”).

Probably quite a few. Two reasons I can see:

First reason is pretty obvious. When money was cheap the objective was to raise as much investment as possible and use that money to build an aggressive roadmap fast. When time is of the essence and cost isn’t a big deal, the first reaction of most managers is going to be to hire people to do more stuff. Not surprising that many companies over-hired – e.g. see https://qz.com/from-overhiring-to-optionality-what-we-can-learn-from-1850267076 and https://stripe.com/gb/newsroom/news/ceo-patrick-collisons-email-to-stripe-employees

Burning loads of VC cash to hire loads of people to build more stuff brings its own set of challenges. The processes and best practices that evolve will work well with these sorts of challenges.  When there is less investment money floating around you need to be leaner and more intentional in where you spend your time. The processes that work best in a leaner environment won’t necessarily be the same as those that worked in the sorts of VC-backed outfits we’ve seen over the last decade.

It’s a common trope that you shouldn’t just pick a process that worked in a company whose brand you admire and expect it to work in your company. What I’m saying here is a bit stronger than that. I’m saying that any product or engineering advice coming out of the VC-backed cash-burning-machine era might need to be chucked in the bin in these leaner times.

It’s not just that a bigger company’s processes might not work for where your company is right now. The sorts of processes that worked in a ZIRP era business model might just not make sense in a leaner era.

Here comes the second reason that makes it even more important for you to question ZIRP-era process advice.

As a company gets bigger, the people who have the time and inclination to write about processes get further and further removed from the reality on the ground. Even in @simfoni it’s difficult for me to know what an individual product iteration really involves for the people doing the work. If you’re reading a blog post by a tech leader of a company with 200  or 1,000 engineers, how confident should you be that the blog reflects reality? Or does it reflect what the writer thinks is happening, or how they would like things to be happening?

A great example of this is the Spotify Model. The Spotify model is (was?) an organizational structure that inspired a lot of imitators until it turned out that even Spotify didn’t use the Spotify model: https://www.agility11.com/blog/2020/6/22/spotify-doesnt-use-the-spotify-model  It was as much a leadership aspiration as it was a statement of reality.

To sum up, I see 2 things combining here:

1. Processes developed in ZIRP-era VC-backed company might fundamentally not work in leaner times
2. The processes as described in blog posts and analyst reports maybe never even existed in real life

So a 2024 resolution for myself, and a call to arms for anyone reading is to “question all the blog posts”. Even more than you normally would.

Except for this one, of course. This one is bang on the money 😀

Agile Software Development 22 years on

The Agile Manifesto came about in Feb 2001. That makes it 22 years old now. There are people commercially writing code today who weren’t even born when it came out.

Goodness, I feel old.

The values that underpin the Agile Manifesto remain sound and the best way to approach your software development. But I have seen many times that in an effort to ‘do agile’, teams lose the ability to ‘be agile‘.

If you want to avoid this trap, bear in mind the context that the Agile Manifesto came out of.

Conventional wisdom at the time was was, for example, spend 1 month scoping the project, 3 months documenting requirements, 12 months building, 3 months testing and 6 months rolling out. This sort of order of things. With checkpoints at each step along the way.

There was a whole generation of project managers who prided themselves on delivering projects on time, on budget, on scope. I was one of them. Yet at the same time, the companies investing in tech would complain of over-runs in all of these factors.

Why the disconnect? Because of the focus on scope (building features) rather than impact (solving problems). As a project manager working in one of these projects you could build a successful career by agreeing a scope, writing it down and delivering it. Then, when the inevitable changes arose you’d handle those as individual ‘change orders’, each adding more scope which you would then deliver on time, on budget and so forth (and get paid more for doing). But the users would end up paying many times as much as initially expected over a much longer timescale before they saw the benefits that they had been looking for.

Agile changed all that by, basically, saying “let’s talk more between the programmers and the users and let’s deliver in smaller increments so we can keep focus on the most important things”.

That was the kernel and the genius of Agile.

At some point things started to go wrong. In my view it’s when Agile became equated with Scrum; anything non-scrum became called Waterfall and therefore not to ever be mentioned again.

Agile is not a methodology. Agile isn’t something you do. Agile is something that following those 4 simple values can help you be.

So as we look back on the arrival of Agile on the scene all those years ago, I urge you to forget about your Kanban and Scrum and Roadmaps and Mob Programming for a moment and just remind yourself of the 4 key values that can sit underneath all these attempts to become more agile in how we build software:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

https://agilemanifesto.org/

The Now/Next/Later Roadmap changed my life

I love ideas that seem so obvious in retrospect. The Now/Next/Later roadmap is one of those: https://www.prodpad.com/blog/how-to-build-a-product-roadmap-everyone-understands/

The traditional roadmap is a group of chevrons or bars set out in quarters one or two years into the future. It says that: In Q1 we will deliver features A and B, in Q2 features C and D etc. Something like the following:

If you can plan this far ahead then, fantastic. But many of us need to be more nimble and to adjust priorities in the face of changing needs and opportunities in the marketplace. For us, this kind of roadmap is too rigid of a way to communicate future product development plans.

Its problems stem from the way it combines prioritisation and timelines into one view. It allows different stakeholders to have very different interpretations of what done looks like for any of these future developments. And it obscures whether we need to do any work now for something that it planned for 3 quarters away.

Now/Next/Later fixes an important part of this by separating out relative priorities from timelines. At Simfoni, implementing Now/Next/Later has helped me have these sorts of conversations:

1. Which of the items in now is genuinely something we should be working on now in support of company OKRs? And is everything in now really well-defined enough for us to be working on it right now?
2. For the stuff that isn’t in now, which pieces should be in next and which pieces should be in later?
3. What requirements/analysis/user testing do we need to do now on items that are in next and later so that we can be ready to build them when the time comes?

I even love the language of Now/Next/Later. Now clearly means something we should be working on right now. The less you have in now the more focussed you can be and the sooner you can get something properly done. Next means we need to get ready for something that we will be working on shortly, so we better firm up exactly what we need to do. And later is altogether more speculative and might need some early stage proof of concept work but it’s not something we should be spending much time discussing at the moment.

How to then apply timelines to the results of the now/next/later work is another topic. But so far I am finding that it helps to make the problem space smaller: we should be able to have pretty firm time-boxed estimates for work in now, and then things will get less precise as we move out into next and later.

All credit to Janna Bastow who invented it, see https://www.prodpad.com/blog/the-birth-of-the-modern-roadmap/ for the history.

First steps in Natural Language Topic Understanding

In https://alanbuxton.wordpress.com/2021/09/21/transformers-for-use-oriented-entity-extraction/ I showed how transformers allowed me to build something more advanced than the generic entity extraction systems that are publicly available out there.

Next step was to see if I can do something useful with this. In past lives customers have told me about the importance of tracking certain signals or events in a company’s lifecycle, e.g. making an acquisition, expanding to a new territory, making a new senior hire etc.

So I gave it a go, initially looking purely at whether I could train an algorithm to pick out key staffing changes. Results below are 20 random topics pulled from my from my first attempt showing the good, bad and ugly. The numbers are the confidence scores that the algorithm chose for each entity in the topic.

I’ll give myself a B for a decent first prototype.

I do wonder who else out there is working on this sort of thing. From what I can see in the market ML is used to classify articles (e.g. “this article is about a new hire”) but I couldn’t see any commercial offering that goes to the level of “which org hired who into what role”.

If I were to take this further I would be training specialist models on each different type of topic. I wonder if there is something like a T5-style model to rule them all that can handle all this kind of intelligent detailed topic understanding?

Title	OSE Immunotherapeutics Announces the Appointment of Dominique Costantini as Interim CEO Following the Departure of Alexis Peyroles
Url	https://www.businesswire.com/news/home/20220116005013/en/OSE-Immunotherapeutics-Announces-the-Appointment-of-Dominique-Costantini-as-Interim-CEO-Following-the-Departure-of-Alexis-Peyroles

Who	What	Role	Org	Effective When
Alexis Peyroles (0.9846990705)	departure (0.943598628)	Chief Executive Officer (0.9995111823)	OSE Immunotherapeutics SA (0.9983804822)	immediately (0.9876502156)
Dominique Costantini (0.9990960956)	appointed (0.9998416901)	interim Chief Executive Officer (0.9983062148)	OSE Immunotherapeutics SA (0.9983804822)	immediately (0.9876502156)
Alexis Peyroles (0.993326962)	departure (0.9623697996)	Chief Executive Officer (0.9994782805)	OSE Immunotherapeutics SA (0.9968072176)
Dominique Costantini (0.9989916682)	appointed (0.9993845224)	interim Chief Executive Officer (0.9982660413)	OSE Immunotherapeutics SA (0.9968072176)

Assessment

Topic is duplicated without the ‘effective immediately’ piece – should only keep the most granular topics

Title	Barclays appoints managing directors for Australia investment banking unit
Url	https://www.reuters.com/markets/funds/barclays-appoints-managing-directors-australia-investment-banking-unit-2022-01-17/

Who	What	Role	Org	Effective When
Duncan Connellan (0.988427639)	appointed (0.9996656179)	managing directors (0.9994463921)	Britain ‘s Barclays Plc (0.9851405621)
Duncan Beattie (0.9959402084)	appointed (0.9996656179)	managing directors (0.9994463921)	Britain ‘s Barclays Plc (0.9851405621)

Assessment

Pulled out the two key items but: didn’t do a great job of the Entity (Britain’s Barclays Plc was treated as one entity) and doesn’t understand the pluralised role name. Model was not trained to look for where the role is based, so haven’t identified that these roles are specifically in Australia

Title	Trulioo Appoints Michael Ramsbacker as Chief Product Officer
Url	https://www.prweb.com/releases/trulioo_appoints_michael_ramsbacker_as_chief_product_officer/prweb18439306.htm

Who	What	Role	Org	Effective When
Michael Ramsbacker (0.999671936)	appointment (0.9997799993)	Chief Product Officer (0.9999740124)	Trulioo (0.9999925494)

Assessment

Got it right

Title	Elastrin Therapeutics Announces Newly Formed Scientific Advisory Board
Url	https://www.businesswire.com/news/home/20220117005220/en/Elastrin-Therapeutics-Announces-Newly-Formed-Scientific-Advisory-Board

Who	What	Role	Org	Effective When
Dr. Pedro M. Quintana Diez (0.9665058851)		chairman (0.9933767915)	Elastrin Therapeutics Inc. (0.9841426611)
Dr. Pedro M. Quintana Diez (0.9665058851)		Scientific Advisory Board (0.9952206612)	Elastrin Therapeutics Inc. (0.9841426611)

Assessment

Correctly extracts key info that Dr Quntana Diez is chairman of the new Scientific Advisory Board but treats these as two roles rather than as one

Title	Toshiba Appoints Andrew McDaniel to Lead Its European Retail Business
Url	https://www.businesswire.com/news/home/20220117005027/en/Toshiba-Appoints-Andrew-McDaniel-to-Lead-Its-European-Retail-Business

Who	What	Role	Org	Effective When
Andrew McDaniel (0.9996804595)		senior vice president of Europe (0.9983366132)	Toshiba Global Commerce Solutions (0.9999386668)	January 15 , 2022 (0.9999966621)
Andrew McDaniel (0.9996804595)		managing director (0.9998098612)	Toshiba Global Commerce Solutions (0.9999386668)	January 15 , 2022 (0.9999966621)

Assessment

Got it right

Title	Cairn Real Estate Holdings Appoints Mark Johnson President of JPAR® – Real Estate
Url	https://www.prweb.com/releases/cairn_real_estate_holdings_appoints_mark_johnson_president_of_jpar_real_estate/prweb18437732.htm

Who	What	Role	Org	Effective When
Mark Johnson (0.9998755455)	appointment (0.955047369)		JPAR® – Real Estate (0.9999427795)

Assessment

Correctly pulls out the appointment but doesn’t identify the role

Title	Fiona Macfarlane and Andrea Nicholls appointed to HSBC Bank Canada Board of Directors
Url	https://www.businesswire.com/news/home/20220117005321/en/Fiona-Macfarlane-and-Andrea-Nicholls-appointed-to-HSBC-Bank-Canada-Board-of-Directors

Who	What	Role	Org	Effective When
Fiona Macfarlane (0.9959855676)	appointed (0.9996260405)	non-executive directors (0.9942650795)	HSBC Bank Canada Board of Directors (0.9947710037)
Andrea Nicholls (0.9999670982)	appointed (0.9996260405)	non-executive directors (0.9942650795)	HSBC Bank Canada Board of Directors (0.9947710037)

Assessment

Got it right

Title	Digital Mountain Announces Industry Veteran Calvin Weeks Joining Team as Director of Digital Forensics & Cybersecurity
Url	https://www.prweb.com/releases/2022/1/prweb18416336.htm

Who	What	Role	Org	Effective When
Calvin Weeks (0.999994576)		Director , Digital Forensics & Cybersecurity (0.999989152)	Digital Mountain , Inc. (0.9999924898)

Assessment

Got the role right but didn’t get the ‘what’

Title	MiniCo Insurance Announces Two Strategic Leadership Promotions
Url	https://www.prweb.com/releases/minico_insurance_announces_two_strategic_leadership_promotions/prweb18437565.htm

Who	What	Role	Org	Effective When
Rick Krouner (0.9899243116)	named (0.9960696697)	President (0.9988073111)	MiniCo Insurance Agency ( MiniCo ) (0.9878121018)
Jim Henry (0.9995553493)	named (0.9960696697)	Specialty Programs division (0.9527196288)	MiniCo Insurance Agency ( MiniCo ) (0.9878121018)
Jim Henry (0.9995553493)	named (0.9960696697)	National Programs division (0.9757707119)	MiniCo Insurance Agency ( MiniCo ) (0.9878121018)
Jim Henry (0.9995553493)	named (0.9960696697)	President (0.9988151789)	MiniCo Insurance Agency ( MiniCo ) (0.9878121018)

Assessment

Similar to the Elastrin story it pulls out the title and the division but treats them as different roles; also only assigns one of the found roles to Mr Krouner. Also is a bit ‘greedy’ at identifying the Org – the part in parentheses is redundant

Title	Stertil-Koni Names Supply Chain Sales Pro Scott Steinhardt as Vice President of Sales
Url	https://www.prweb.com/releases/stertil_koni_names_supply_chain_sales_pro_scott_steinhardt_as_vice_president_of_sales/prweb18430929.htm

Who	What	Role	Org	Effective When
Scott Steinhardt (0.9999918938)	joined (0.9999970198)	Vice President of Sales (0.9999983311)	Stertil-Koni (0.9999969602)

Assessment

Got it right

The Save Icon is dead! Long live the Save Icon!

Or, some notes on evolution in language and metaphors.

Look: LibreOffice have gone and updated their ‘save’ icon for the internet age!

Whereas Microsoft is still languishing in the days of 3.5mm floppy disks:

It’s a helpful reminder that language and metaphors don’t stand still. In fact, there’s nothing more open source than language itself. Anyone can fork any language and make any update which may or may not then get adopted by the community.

Even the language around the 3.5mm floppy disks highlights another change in metaphors. Their predecessors, the 5.25″ floppy disks were definitely floppy, but you’d have to use quite a lot of imagination to find any floppiness in a 3.5mm disk.

Quirks of history led to the following evolution:

1. The genuinely floppy disk (5.25″) is called a ‘floppy disk’
2. Its next generation (3.5mm) is in a hard case but is still called a floppy disk
3. Application developers adopt the hard-cased floppy disk as the save icon
4. Which now becomes known as the save icon but no-one knows why
5. Until eventually it gets replaced by something that is more familiar to people – a download to your local machine icon

Unless you and I share the same history then what is intuitive for me may well be counter-intuitive to you.

My kids (for example) have no idea that the 3.5mm floppy disk icon means “save”. They can learn this but they won’t get the meaning of it in the same way as someone who has carried around handfuls of these disk at a time. A “download” icon is much more intuitive for them. On the other hand, I am so used to the floppy disk icon meaning save that it took me some time to figure out that LibreOffice had changed it – goes to show that you look for what you expect to find.

Some more entertaining discussion around the save icon: https://uxdesign.cc/the-floppy-disk-save-icon-visual-language-of-an-era-long-gone-93f74efc9f9

A non-tech example of metaphors and their evolution: I only learnt last week the backstory behind a ‘reverse ferret‘, even though I’ve seen Private Eye use it all the time (or perhaps they are just using it more in these recent days). Now I know the history I’ll understand better the joke whenever they use it.

Management and product development lessons from the 1950’s

In 1955, Elihu Katz and Paul Lazarsfeld published “Personal Influence“. This studied how small-group dynamics moderate or influence mass media messaging. For example how people decide who to vote for, which brand of lipstick to use, or which movie to go and watch.

Reading this in 2018 it’s striking to see how much is still valid. I’m not posting this to provide tremendous new insights. Any insights here are over 60 years old. Apparently, human behaviour doesn’t change very much over the generations.

How people choose their leaders

In order to become a leader, one must share prevailing opinions and attitudes. (p52)

They cite a 1952 study on children in a day nursery in which kids with “leadership qualities” were separated from the other children who were then placed into groups of 3-6. These new groups created their own “traditions” (e.g. who sits where, group jargon, division of who plays with what objects). The original leaders were then re-introduced:

In every case, when an old leader attempted to assert authority which went contrary to a newly established “tradition” of the group, the group did not respond. Some of the leaders, as a matter of fact, never returned to power. Others, who were successful, did achieve leadership once more but only after they had completely identified with the new “tradition” and participated in it themselves. (p52)

Or another 1952 study amongst a religious interest group, a political group, a medical fraternity and a medical sorority:

[T]hose who had been chosen as leaders were much more accurate in judging group opinion … But this was so only on the matters which were relevant to the group’s interest – medicine for the medical group, politics for the political group, etc. It seems reasonable to conclude … that leaders of groups like this are chosen, in part at least, because of recognized qualities of ‘sensitivity’ to other members of the group. (p102)

A succinct argument as to why people who want to become leaders need to first spend time listening.

Group participation improves take-up

Here’s are some more 1952 studies that the authors cite:

1. A study in a maternity hospital in which “some mothers were given individual instruction .. and others were formed into groups of six and guided in a discussion which culminated in a [group] ‘decision’ [to follow the instruction.” The participants in the group dicussion adhered “much more closely” to the child-care programme. (pp74-75).
2. A study comparing a lecture approach vs a group discussion on “the nutritional and patriotic justifications for the wartime food campaign to buy and serve ‘unpopular’ cuts of meat. 3% of those involved in the lecture followed the desired course of action, vs 32% of those in the group discussion.

Worth bearing in mind in the next meeting you host, or the next corporate communication you send out.

How small groups construct their reality

So many things in the world are inaccessible to direct empirical observation that individuals must continually rely on each other for making sense out of things. (p55)

Apparently 1952 was a bumper year for social sciences. Here is another 1952 study in which individuals were asked to decide how far and in which direction a point of light was moving. The catch was that the point of light was static. The study found that:

1. When people were shown the light individually, they would make their own judgment of how it was moving. When they were later put into small groups of 2 or 3, “[e]ach of the subjects based his first few estimates on his previously established standard, but confronted, this time, with the dissenting judgments of the others each gave way somewhat until a new, group standard became established.”
2. If a group session came first, the group would achieve a consensus of how the light was moving, and each individual would adopt the group’s consensus as their own position.

The way reality is generated by social groups is something to bear in mind during user research activities.

How the make-up of a group affects quality of communication

You guessed it, it’s another 1952 study that found that:

1. Rank in the group affects how people communicate. Specifically: “[P]-erson-to-person messaged are directed at the more popular group members and thus may be said to move upward in the hierarchy, while communication from one person to several others tends to flow down” (p89).
2. As groups get larger (from 3 to 8) “more and more communication is directed to one member of the group, thus reducing the relative amount of interchange among all members with each other. At the same time the recipient of this increased attention begins to direct more and more of his remarks to the group as a whole, and proportionately less to specific individuals.” (pp89-90)

I’m sure these two findings will ring very true of many meetings you’ve been in. I suspect that the person who becomes the centralising leader in these communications might not even realise the role they are playing. Reading this makes me more keen to try out the kind of silent meetings approach they use at Square.

 

 

How long will this feature take?

Be clear on someone’s definition of done when trying to communicate what it will take to build a feature.

Planning software development timescales is hard. As an industry we have moved away from the detailed Gantt charts and their illusion of total clarity and control. Basecamp have recently been talking about the joys of using Hill Charts to better communicate project statuses. The folk at ProdPad have been championing, for a long time, the idea of a flexible, transparent roadmap instead of committing to timelines.

That’s all well and good if you are preaching to the choir. But if you are working in a startup and the CEO needs to make a build or buy decision for a piece of software, you need to make sure that you have some way of weighing up the likely costs and efforts of any new feature you commit to build. It’s not good enough to just prioritise requests and drop them in the backlog.

The excellent Programmer Time Translation Table is a surprisingly accurate way of interpreting developer time estimates. My own rule of thumb is similar to Anders’ project manager. I usually triple anything a developer tells me because you build everything at least 3 times: once based on the developer’s interpretation of the requirements; once to convert that into what the product owner wanted; and once into what the end users will use. But even these approaches only look at things from the developer’s point of view, based on a developer’s “definition of done”. The overall puzzle can be much bigger than that.

For example, the startup CEO who is trying to figure out if we should invest in Feature X probably has a much longer range “definition of done” than “when can we release a beta version”. For example: “When will this make an impact on my revenues” or “when will this improve my user churn rates”. Part of the CTO job is to help make that decision from the business point of view in addition to what seems to be interesting from a tech angle.

For example, consider these two answers to the same question “When will the feature be done?”.

1. The dev team is working on it in the current iteration, assuming testing goes well it will be released in 2 weeks.
2. The current set of requirements is currently on target to release in 2 weeks. We will then need to do some monitoring over the next month or two so that we can iron out any issues that we spot in production and build any high priority enhancements that the users need. After that we will need to keep working on enhancements, customer feedback and scalability/security improvements so probably should expect to dedicate X effort on an ongoing basis over the next year.

Two examples from my experience:

A B2B system used primarily by internal staff. It took us about 6 weeks to release the first version from initial brainstorming on it. Then it took about another two months to get the first person to use it live. Within 2 years it was contributing 20% of our revenues, and people couldn’t live without it.

An end user feature that we felt would differentiate us from the competition. This was pretty technically involved so the backend work kept someone busy for a couple months. After some user testing we realised that the UI was going to need some imaginative work to get right. Eventually it got released. Two months after release the take-up was pretty unimpressive. But 5 years later that feature was fully embedded and it seems that everyone is using it.

What is the right “definition of done” for both of these projects? Depends on who is asking. It’s as well to be clear on what definition they are using before you answer. The right answer might be in the range of months or years, not hours or weeks.

How to make 3000 look like 8000, or #marketing

See below how CarGiant, a UK-based retailer of used cars does it.

First off, the organic search results:

If you search for Car Giant they have already anchored in your mind that they have over 8000 vehicles

So now you land on the home page and note how the “over 8000” has now changed to “up to 8000”. That could be a whole lot of a smaller number. So let’s do a search for all vehicles up to the maximum price available.

And there you go, just under 3000 cars. Which is definitely “under 8000” as promised, but by this time you’ve still got in your head that Car Giant is a truly giant organisation with 8000 or more vehicles to sell you.

See also https://en.wikipedia.org/wiki/Anchoring#In_negotiations