By Richard Powell

Getting to yes is a great book on principled negotiation, an approach that seeks to align competing objectives and move past positional bargaining.

The 22 immutable laws of marketing whilst a little dated is still very relevant. How many of the tech products we know and love have followed these rules? I’d say quite a few.

How to create tech prodcts customers love is a pretty broad breakdown of the field of product management. I particuarly love it’s insights into how to structure cross collaborative teams for success. Recommended reading for any product manager.

Sprint is a framework for solving big product problems in a testable, collaborative way in just 5 days. We’ve used a similar approach for big design projects at Fullscript.

Humble Inquiry is all about building positive relationships by asking questions. Something that’s essential to the kind of soft leadership that can help product managers be sucessfull.

Crossing the Chasm describes how many high growth startups can die if they are unable to branch out from a small niche to a late adopting majority. More importantly it describes how to avoid it.

Digging Beyond 

A colleague says to you "we need to develop X". Do you go ahead and develop it? Or do you do your research and translate their solution to the underlying problem so that you can propose an more impactfull solution?

A customer says "I can't use this". Why? Is it a design language issue? Missing functionality? Did you develop the wrong thing? Is this the wrong user type.

To dig beyond I find the most important question is why. Why? Why? Why? Why? And finally... Why?

Speaking The Right Language

Product sits at the intersection between design, development, support, customer success, marketing, sales, leadership, data and more. In one project, product might translate:

An opportunity into potential business impact.

An opportunity into a feature.

The feature into development tasks and timelines.

The feature into support documentation.

A release into actual measurable business impact.

A release into marketing and sales messaging.

To do all this, product needs to speak many different languages. Speaking the right language is about knowing who your audience is and what they care about. In this regard speaking at conferences, delivering workshops and writing articles has helped me a great deal. As has been highly curious about how each function of a business contributes to it's success.

The Big Picture

In every company I've worked for I've always strived to understand the big picture. Now I can help steer the big picture at a company that's growing at pace, has an awesome development culture and is doing something really meaningful. I’m very grateful.

What Rough Edges?

The Server Density UI definitely has some rough edges. This isn’t something I’m embarrassed about; instead I prefer to be honest about these things so they can be addressed.

CSS: We have one CSS file that is over 5000 lines long. It hides plenty of dead CSS, and it is very difficult to work with. It also contains far too many uses of !important.

Backbone Views: Our old Backbone views tend to contain UI elements that aren’t usability tested, are less composable and less performant than their React counterparts. In our codebase, Backbone views tend to not have unit tests, whereas our React components always do.

Backbone Models: Transitioning to Redux means we are in a phase where we have redux code that duplicates Backbone Models/Collections. Fixing this duplication would lead to less loading states as data fetched for one page is easily shared with another page.

Improving the situation

If we recognise these rough edges (and we should) we should start to think about what to do about them. How do we know it’s a rough edge? How do we know if it’s getting better? How do we measure it?

If it’s measurable we can track it over time, but how? At Server Density we use simple scripts like measure React component re-use to track 4 areas of the codebase every month:

Asset file size: This is more about how much duplicate or dead code we managed to remove. Byte counting is not that useful but removing dead or duplicate code is.

CSS health: Our new CSS is composed of little files where each file has 1:1 mapping to a component and a very specific namespace. Our old CSS is a very large file, a lot of which can probably be deleted. Plus, our old CSS uses !important too much and has weak namespaces or selector depth that is too deep.

Component reuse: This is about how generic and re-usable our components are, which is about productivity and UI consistency. This read-me is a good overview.

Backbone views: How successful we are at removing Backbone views in favour of more usable, more consistent, better tested, more composable React components.

Every month we measure these stats and add them to a spreadsheet, which allows us to compare where we are this month vs last month.

Does this work?

Sometimes it’s easy to see a benefit. Prior to monthly stats the CSS file-size was increasing, but now it’s decreased every month for 10 months by 27% overall. The important point here is the amount of dead or undesirable code that has been removed or replaced and how much easier the CSS is to work with now.

Tracking JavaScript file-size has also been positive. After 10 months of monitoring, the file-size is roughly the same. Pretty good considering we ship code almost every day, and have released major features like alert costs in that time. Again, the file size is not the important point, it’s the increased composability and the removal of dead code that this indicates which is important.

Other times it’s harder to say. Component composability has increased, and anecdotally this has improved productivity because new features have comprised mostly of pre-existing code. However, I can’t say if this would have happened without the stats. I also think focussing too much on further increases would make the codebase too tightly woven.

The danger inherent in focusing too much on instances per component reveals some interesting take aways from monitoring stats like these:

Stats should be a way to tell the story of a code-base, and should not be the end goal.

Stats should be taken with a pinch of salt.

The stats you monitor might have to change as a code-base changes.

Stats need to be really specific to the codebase. Stats that are valuable for one codebase might not be valuable for another.

React

Almost 3 years ago we took the decision to switch to React. This has substantially improved the lives of our developers and our customers:

Because components are a function of props and state, they are easy to unit test. This opportunity allowed us to enforce unit tests at the view layer for the first time, making the UI more robust and less prone to regressions.

Because components are much quicker to implement than backbone views we had more time. This led to two new policies; new functionality must be usability tested and new functionality must support keyboard controls.

Because components are so much more composable than Backbone views we had a real opportunity to improve productivity and user-interface consistency. To make sure we were doing this we started to measure component re-use and document generic components.

These opportunities have proven to be huge wins for improving productivity, reducing regressions and improving usability.

However, there have been costs; the time it takes to convert backbone views to react components, the extra complexity of maintaining two very different approaches within one codebase, the cost of implementing bad components due to relative naivety and learning React.

In this case was the cost worth it? Yes, absolutely. But that doesn’t mean the cost is without consequence, in fact I expect us to be dealing with these costs for many months/years to come.

Redux

Recently we’ve taken the decision to move our data layer from backbone to Redux. Redux’s opportunities are:

Debugging how data changes over time is now much simpler thanks to immutability and tools like redux debugger

With Backbone (in our codebase at-least) each view instantiates the data it needs. This means different views will often fetch the same data multiple times as a user navigates the app. With Redux, after the first fetch, data is always available. This means the user should only ever see a loading state for specific data once, rather than several times.

Still there is a cost: We now have redux code duplicating backbone model/collection code, we’ve had to add seamless-immutable to our codebase, initial development has been slower (but is speeding up), and we’ve had to figure out how to hook backbone events to Redux action creators (eww).

Will this cost be worth it? Yes, eventually, mostly because we will be able to remove so many loading states from the app and massively improve user experience. But this will take many months/years to be completely fulfil and in the mean time we’ll be dealing with the costs.

Why does this matter?

I think using opportunity and cost as a framework for making technical decisions is important. Think:

What are the opportunities?

How long until we realise these opportunities?

What are the costs?

How long until we pay back these costs?

How can we measure if we capitalise these opportunities?

Do the opportunities substantially outweigh the costs?

Hindsight is a wonderful tool. It can and should be used to judge past decisions to improve future decisions.

At Server Density we used Backbone for 2 years without upgrading to any of the more advanced variants like Ampersand.js and Marionette. All that time I wondered whether upgrading would be worth it, but with hindsight I’m glad we didn’t. If we had upgraded we’d still be dealing with upgrade costs as well as the costs of switching to React & Redux.

Meet-ups and lightning talks are a great place to gain experience. Send the organisers an email and say you would like to present and what your experience is.

Rehearse, multiple times. On your own at first and then in front of some-one you trust to give honest feedback and be very grateful to this person. After each rehearsal improve the slides. If there is a slide, quote or concept you consistently find difficult to articulate remove it. 

Stories are powerful. Even just saying the word story can have a positive effect on how attentive an audience is.

A picture says a thousand words but a video can say a million, especially if you are trying to explain something that is time-based, like user interaction.

Less is more. Put less information on your slides and cover less information in your presentation. Presentations that try to cover too much are rarely successful. 

Watching a video of yourself presenting is the only real way to pick up on bad habits and put an end to them. It's painful, but it's worth it.

Don't think out-loud. Instead of saying "um", or "er", or "like", stop speaking for as long as it takes to formulate the next sentence. It won't be that long and the break will do your presentation good.

Don't live code. I've seen presentations by very clever, very confident programmers falter as soon as they switch to their text editor. You can probably show the concepts you would live code in slides anyway.

Ask a question and then answer it. Or introduce a problem and then provide the solution. You can do this for the whole of the presentation, or you can do this multiple times through the course of it. This keeps your audience thinking.

Design your presentation for your audience. Is your audience made up of managers, designers, developers, others or a mixture? Designers might not be interested in code samples, but developers might be disappointed if there aren't any.

Define a clear structure for your presentation and if you have time, tell your audience what that structure is. This might not apply to shorter presentations.

If your presentation is split into sections choose a color scheme for each section.  This helps you be aware how you talk is progressing compared the the time you have available, but it also tells the audience that the topic has changed.

Be yourself. You may really like a particular presentation but if that presenter has a style that does not match your personality don't try to copy it. 

Be opinionated. Sure, acknowledge the subtleties in a statement, but don't shy away from being bold in what you say.

Define what you will cover, what you won't cover and experience that will be required to enjoy the workshop. Make this very obvious to people before they sign up.

People learn differently so use a variety of teaching methods. I usually have a presentation, code demonstrations and then exercises.

Keep live coding to a minimum. For me this means uncommenting and re-commenting code not writing lines and lines of it. 

Exercises should be well documented and flexible so that people can complete them at their own pace and in their own time.

For every new method, function or concept try to provide a link to documentation or a blog post that contains an alternative explanation.

Always ask "does everyone understand" and then ask again, but phrased differently a few seconds later. It's amazing how many times people will stay quiet the first time, but then say they don't understand the second time.

Focus on concepts first and syntax second; If some-one understands a concept they can learn the syntax through repetition. It's harder the other way around. 

Use analogies where appropriate, but test your analogies on people who understand the concept before the workshop.

Try to provide enough material so that it will be impossible to complete it all in the workshop. People love to take material away with them.

Define your development environment and if necessary ask participants to install this before the workshop. You don't want to have to set this up on the day

Encourage questions during the workshop and provide a way in which participants can get more help after the workshop.