People quickly accomplishing ambitious things together

· Concepts, Planning, Product, Teams · Patrick Smith

Patrick Collison of Stripe has started putting together a list of ‘examples of people quickly accomplishing ambitious things together.’ Sometimes an idea comes screaming into the world.

Xerox Alto. Work on the Xerox Alto, the first GUI-oriented computer, started in November 1972 because of a bet: “Chuck said that a futuristic computer could be done ‘in three months’ and a Xerox exec bet him a case of wine that it couldn’t be done”.

Git. Linus Torvalds started working on Git on April 3 2005. It was self-hosting 4 days later. On April 20 2005, 17 days after work commenced, Linux 2.6.12-rc3 was publicly released with Git.

BankAmericard. Dee Hock was given 90 days to launch the BankAmericard card (which became the Visa card), starting from scratch. He did. In that period, he signed up more than 100,000 customers.

Amazon Prime. Amazon started to implement the first version of Amazon Prime in late 2004 and announced it on February 2 2005, six weeks later.

Don’t make your developer experience improvement a tax the user pays

· Planning, Product, Teams, UX, Workflow · Patrick Smith

Sometimes it feels like we decide the developer experience is more front of mind than the user experience.

Or: DX > UX.

Why is that? Does web development today feel like such a beast that I must wield a powerful weapon with which to conquer it?

We need the latest browser features to build web apps. If they are not available in every user’s browser, we will write the code we prefer and transpile or package it up into to a common lingo.

The team really wants to use this new language or framework, so we should adopt it and be cutting edge! We’ll be more attractive in the industry so hiring will be easier.

It’s quicker for us to choose the same tech everyone else is using, because they have solved lots of problems that make it sometimes tricky and there’s a huge ecosystem of ready-to-go components and plugins. We’ll move so fast! ?

While I think these considerations should be discussed, where is the user here?

Will it be easier for the user? Will they move quicker than they had before? Will they be provided something ready-to-go to solve the problem they have? Will they really want to use what you’ve made? What did they need anyway?

If you have failed here for the user, or if the developer experience is more satisfying to the developers than the user experience is to the users, what has been gained? If it’s fast for the team to see changes live but slow for the user to load, that’s a tax the user is paying for. Was it worth it? Why should they pay?

As developers our natural sense is to pick up on what makes a compelling and fresh developer experience that will lead us to learn interesting new concepts and be involved in the currents of the industry. But does the user care? Are you creating a large tax for them to swallow? Will your team get swept away from the user? What value does the user get for paying that tax?

Keep the user experience front of mind. Talk with the user and measure so that you know that your UX is at least as compelling as your DX. Keep the tax from your DX choice low.

Lessons as a Developer from Web Directions Product

· Product, Teams · Patrick Smith

In the beginning of August 2019 I attended the Product focused Web Directions conference with Myles, another Cogent engineer. Here are my take aways from two days I found very valuable as a developer, gaining different insights than I would usually find at an engineering-focused conference. I expect I’ll go to many more product focused events in the future.

David Demaree, Product Manager of Google’s Material Design, gave a fantastic opening keynote. He focused on how to define what does a product manager do, and the attributes that you can measure a product manager by.

These attributes are: Strategy, Execution, Storytelling, Domain Knowledge, and Leadership. Each person can be measured for each of these traits, and will make up what David described as a product manager. These can plotted within a pentagon like below, with a number of examples demonstrating strengths and weaknesses across a range of hypothetical product managers.

David also went into the importance of narrative, as a way to create understanding between the team and the product, and between users and the product. They use storytelling to allow users to understand how the product relates to them. These user stories are brought to the team further deepen their understanding of not just what they are building, but for who and why. The team also needs something concrete and actionable. A specific solution for a specific problem for a specific user market.

Your metrics should not just be numbers, but be associated with a narrative to provide meaning to the changes in those numbers.

These perhaps might not be novel ideas, but for me it was a compelling framing. A system that makes intuitive sense. David used to be an engineer at Typekit, and this talk got me excited that perhaps there could be product management or aspects in my future. He mentioned a quote from Leland Rechis @leland, a product manager at Google — “Product managers take in a firehose of information and output it as structure”. Sounds like what we often do in software engineering.

Anna Harrison from Thnx talked about ‘Hum’ within teams. It’s a concept that sounds a bit odd at first, but through this talk I am convinced that this is something I have observed and experienced in teams. Similar concepts are team culture, cohesion, collaboration, communication. She argues you can’t just scale Hum. Teams prefer to be somewhere on the scale from Chaos to Order. So keep them where they prefer: when projects change and mature, keep teams together and where they work best. Don’t thoughtless break teams up as the Hum can break too — it takes roughly six months to grow trust within a team. So all managers should be mindful of this effect.

Nicole Brolan, Chief Product Officer at Seek, gave really great concrete stories of projects and how they had failed or how their team had to tried to avoid failure. Often their attempts to bet on the right horse ends up backfiring. Teams want to act decisively, but by doing so can become so emotionally invested that they arrive at the wrong solution. So Nicole suggested casting a wider net with techniques to avoid confirmation bias.

There were quite a few great quotes from various talks:

  • “It takes 7 minutes for the mood of a leader to infect the team” — Michelle McQuad, MAPP
  • “Out of the crooked timber of humanity, no straight thing was ever made” — Immanuel Kant
  • The IKEA effect — people place a disproportionately high value on products they partially create.

Day two began with yet another note with Sherif Mansour, a Distinguished Product Manager at Atlassian. His unusual job title was explained in the talk, as Atlassian offers two paths for senior staff: either they can go into management within their area (design, development, product management) or they further specialise in their area as an individual contributor without the management side.

This addressed to common problem of people going into management who were not suited or not interested in management because they had no other way to climb the ladder.

Sherif encouraged common product management tasks such as customer interviews, personas, story mapping, surveys, data analysis to always be done with other members of the team and never alone by the manager. This meant the learning was shared instead of having to be re-communicated back to the team, and the team was far more involved in the understanding of who the product was for and why it mattered to them.

Build-a-Box was a way to involve, yes, storytelling again and a way for teams to get more involved. People would use pens and paper to draw what the product would say and look like if it were sold on the shelf in a cardboard box. It can work for both the entire product and a particular feature.

On the topic of planning for the next ten years of your career, Sherif encouraged us to write down the activities we want to be doing in ten years instead of what title we want in ten years. Again this resonated with me, as I have not always felt content with being put into a ‘developer’ or ‘programmer‘ box, and if I want to draw wireframes or do user research it seems I must move into the ‘designer’ or ‘product manager’ box. Perhaps in ten years, today’s usual roles will have shifted significantly with new ones formed.

Helping with this multi-angled view is the PM Craft Triangle, which plots people within the three axis of general manager, artist, and scientist. Sherif said practically no-one sits at dead centre, but rather people tend toward one or two of these traits. I plotted myself near the artist corner, looking at management as a skill I want to grow in, and scientist as something that has never really captured my attention.

Linked: Fast Software, the Best Software by Craig Mod

· Planning, Product · Patrick Smith

Speed and reliability are often intuited hand-in-hand. Speed can be a good proxy for general engineering quality. If an application slows down on simple tasks, then it can mean the engineers aren’t obsessive detail sticklers. Not always, but it can mean disastrous other issues lurk.

But why is slow bad? Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow. When the nerds upon Nerd Hill fight to the death over Vi and Emacs, it’s partly because they have such a strong affinity for the flow of the application and its meldiness. They have invested. The Tool Is Good, so they feel. Not breaking flow is an axiom of great tools.

Lots of great points in this post from Craig Mod. It can be contrasted with the point that I don’t believe teams should prematurely optimize or prioritize application speed over meeting user needs.

However — if an application is noticeably slow, especially for common tasks, I will feel annoyed every time I use it. It feels as though a shortcut has been taken for the development team’s benefit (and not mine), or maybe they just don’t know what they’re doing.

Mazda removes touchscreens from its cars

· Design, Product · Patrick Smith

“Doing our research, when a driver would reach towards a touch-screen interface in any vehicle, they would unintentionally apply torque to the steering wheel, and the vehicle would drift out of its lane position,” said Matthew Valbuena, Mazda North America’s lead engineer for HMI and infotainment.

“And of course with a touchscreen you have to be looking at the screen while you’re touching…so for that reason we were comfortable removing the touch-screen functionality,” he added.

The head-up display that top trims of the Mazda 3 get is now projected onto the windshield. The amount of time it takes the eyes to focus on the head-up display is greatly reduced because it’s now focused on a point 7.5 feet ahead of the driver.

I think this shows that just because a technology seems better (touchscreens are in all our phones!) or is newer (everything analogue should become more digital over time!) does not mean it will be a better user experience.

Read the article here