There are only a few instances when I wish I could travel back in time. One is when I’m reading the kid’s menu. One is when I stumble upon Bill and Ted’s Excellent Adventure on TBS. And one is after I’ve launched a new product or campaign.
You and I may share that last one.
Though we typically know the T’s are crossed and I’s are dotted, it’s the pesky unknowns us marketers wrestle with before a new product launch that keep us up at night. Things like: Is the product’s name right? Is the copy clear, but boring? Clever, but convoluted? Is the value as obvious as it should be?
Beyond messaging, most often, it comes down to whether your product’s positioning is right from the start; whether you set the product up in the right conditions and market category in the first place.
We all know the market is more saturated than ever. But what if, instead of fighting it, we used that momentum to our advantage?
April Dunford is the Founder of Rocket Launch Marketing, the former VP of Marketing for a series of high-growth startups and previous executive at big-wig companies like IBM and Nortel. She’s also a speaker, author and in-demand consultant specializing in product positioning. Advising companies on go-to-market strategy and messaging, she ensures they’re going after the right category and communicating their offering in a way that grabs prospects’ attention and makes its value crystal clear.
Basically, April knows her stuff. And she’ll be bringing her smarts to the CTAConf stage in August! But we have the patience of a toddler waiting for an iPad to charge, so we peppered her with some burning questions in anticipation of her talk. She was the top-rated speaker at last year’s conference, so we know this year’s gonna be good. You can enjoy a little time traveling to 2017 via the clip below:
Check out our Q&A with April below and keep your eyes peeled for the exclusive-to-everyone-who-reads-this-post discount code to see her in person.
First thing’s first: What exactly is product positioning and how does it differ from brand positioning?
April: You might say “Positioning” has its own positioning problem! It’s such a misunderstood concept. For some folks it’s mainly a messaging exercise, while others associate it very closely with branding. But positioning is much, much broader than either of those things.
Product positioning describes the specific market you intend to win and why you are uniquely qualified to win it. It’s the underpinning of your go-to-market strategy and impacts everything from marketing to sales, to customer success and the product itself.
What’s the first thing a client asks when you sit down with them?
April: Most CEOs don’t know it’s a product positioning problem they have. They know their customers have a hard time understanding what their product is all about and why they should care. That confusion results in long sales cycles, low close rates and poor marketing campaign performance.
A lot of the work I do is centered around teaching folks how to create context for their products by focusing on making value obvious to customers. Positioning as a concept isn’t new but, until now, we’ve all been pretty terrible at actually doing the work it requires. I teach companies a process for finding and delivering the best position for their products.
What’s the most common mistake you’ve seen businesses make with their go-to-market strategy?
April: Hands down, the most common mistake I see is companies trying to market to a set of customers that is much too broad. The reasoning is that, by going after a massive market, it will be easier to claim a small piece of it.
In reality, the opposite is true. Broad targeting puts your offering in direct competition with established market leaders that can both out-market and out-sell you. Beyond that, it leads to diluted messaging that waters down your best features and differentiators.
The easier—and far more effective thing to do—is target a smaller slice of customers who are highly suited to your product’s key features and the distinct value they can deliver.
Customers who most acutely feel the pain you address will be the most excited about your solution to that pain. They’ll pay you more, close faster and love your product so much they’ll end up marketing it for you. (Editor’s note: AKA the Holy Grail of marketing.)
Once you’ve established yourself with these highly suitable customers, you can build on your strengths and start to expand your targets to larger markets.
Can you tell us about the most challenging product positioning case you’ve worked on?
April: At IBM, I led the launch of a family of products that demanded an entirely new market category built from scratch. We had to convince customers, experts and analysts that certain market forces existed and would inevitably redraw the lines around existing market categories. On top of that, I had to convince them that IBM was the only company capable of drawing those lines.
There was also a catch: The products we had in that family weren’t particularly innovative on their own, at least not at the beginning. So the story itself hinged on convincing people that all of this revolutionary change was going to be sparked by the innovative combination of some pretty ho-hum products.
We managed to pull it off through sheer guts, a sprinkling of good luck and the deep marketing talent of my team at the time. But mainly, guts.
Your upcoming talk at CTAConf is about how to turn “marketing headwinds into tailwinds.” What do you mean by that?
April: In any market category, you’ll encounter extremely powerful forces that can either work for you or against you.
We often position our products in markets with strong competitors who are already perceived as leaders. Like swimming upstream, or fighting headwinds, we have to work extra hard to win in that environment.
Luckily, most products can be positioned in many different markets that offer greater chances of success. We just have to find ones where that inherent force is pushing us forward, like a tailwind, instead of pushing back on us.
In my talk, I’m going to outline exactly how you can use existing market forces to your advantage and grow revenue faster.
Want to hear this talk at CTAConf 2018? Get 10% off all Early Bird tickets ($80 off for General Attendees) by using the code “AprilCTAConf2018” at checkout.
What should marketers consider, before anything else, when launching a new product?
April: The success of a launch depends on how well you understand three things:
The problem your product solves and the competition it faces.
The true value your product delivers for customers.
Which types of customers care the most about that value and, most importantly, why?
If you’ve got these down, you’ll know exactly who you need to reach, the channels you need to use to reach those people and the value proposition you need to communicate.
What should marketers be doing differently now in terms of product positioning vs. five years ago?
April: We should start doing it! Most companies don’t deliberately position their product. They assume a default positioning based on how they first thought about it.
For example, say you’ve built a new email client. But after you got it into the market, you got some feedback, added or removed features and continued to iterate on it. Now you may have a solution that’s best positioned as a “group chat” or “social network” or “team collaboration tool” instead of focusing on email capabilities.
The market frame of reference you choose will completely change the way customers perceive your product and their expectations around pricing, features, support and your competitors.
Because the markets are more crowded, more competitive and shifting faster than they ever have before, we can’t get away with ignoring product positioning if we want our products to be successful.
Get every actionable detail of April’s positioning framework and go-to-market guide in her upcoming talk at Call to Action Conference, this August 27-29. Use the code “AprilCTAConf2018” at checkout for 10% off single, group and customer rates (that’s on top of the Early Bird discount, ending May 31st)! Want more reasons to go? Click here for a bunch of ‘em.
Working Together: How Designers And Developers Can Communicate To Create Better Projects
Among the most popular suggestions on Smashing Magazine’s Content User Suggestions board is the need of learning more about the interaction and communication between designers and developers. There are probably several articles worth of very specific things that could be covered here, but I thought I would kick things off with a general post rounding up some experiences on the subject.
Given the wide range of skills held by the line-up at our upcoming SmashingConf Toronto — a fully live, no-slides-allowed event, I decided to solicit some feedback. I’ve wrapped those up with my own experience of 20 years working alongside designers and other developers. I hope you will add your own experiences in the comments.
Some tips work best when you can be in the same room as your team, and others are helpful for the remote worker or freelancer. What shines through all of the advice, however, is the need to respect each other, and the fact that everyone is working to try and create the best outcome for the project.
Working Remotely And Staying Connected
The nomadic lifestyle is not right for everyone, but the only way to know for sure is to try. If you can afford to take the risk, go for it. Javier Cuello shares his experience and insights from his four years of travel and work. Read article →
For many years, my own web development company operated as an outsourced web development provider for design agencies. This involved doing everything from front-end development to implementing e-commerce and custom content management solutions. Our direct client was the designer or design agency who had brought us on board to help with the development aspect of the work, however, in an ideal situation, we would be part of the team working to deliver a great end result to the end client.
Sometimes this relationship worked well. We would feel a valued part of the team, our ideas and experience would count, we would work with the designers to come up with the best solution within budgetary, time, and other constraints.
In many cases, however, no attempt was made to form a team. The design agency would throw a picture of a website as a PDF file over the fence to us, then move on to work on their next project. There was little room for collaboration, and often the designer who had created the files was busy on some other work when we came back with questions.
It was an unsatisfactory way to work for everyone. We would be frustrated because we did not have a chance to help ensure that what was designed was possible to be built in a performant and accessible way, within the time and budget agreed on. The designer of the project would be frustrated: Why were these developers asking so many questions? Can they not just build the website as I have designed? Why are the fonts not the size I wanted?
The Waterfall versus Agile argument might be raised here. The situation where a PDF is thrown over the fence is often cited as an example of how bad a Waterfall approach is. Still, working in a fully Agile way is often not possible for teams made of freelancers or separate parties doing different parts of the work. Therefore, in reading these suggestions, look at them through the lens of the projects you work on. However, try not to completely discount something as unworkable because you can’t use the full process. There are often things we can take without needing to fully adopt one methodology or another.
Setting Up A Project For Success
I came to realize that very often the success of failure of the collaboration started before we even won the project, with the way in which we proposed the working relationship. We had to explain upfront that experience had taught us that the approach of us being handed a PDF, quoting and returning a website did not give the best results.
Projects that were successful had a far more iterative approach. It might not be possible to have us work alongside the designers or in a more Agile way. However, having a number of rounds of design and development with time for feedback from each side went a long way to prevent the frustrations of a method where work was completed by each side independently.
Creating Working Relationships
Having longer-term relationships with an agency, spanning a number of projects worked well. We got to know the designers, learned how they worked, could anticipate their questions and ensure that we answered them upfront. We were able to share development knowledge, the things that made a design easier or harder to implement which would, therefore, have an impact on time and budget. They were able to communicate better with us in order to explain why a certain design element was vital, even if it was going to add complexity.
For many freelance designers and developers, and also for those people who work for a distributed company, communication can become mostly text-based. This can make it particularly hard to build relationships. There might be a lot of communication — by email, in Slack, or through messages on a project management platform such as Basecamp. However, all of these methods leave us without the visual cues we might pick up from in-person meetings. An email we see as to the point may come across to the reader as if we are angry. The quick-fire nature of tools such as Slack might leave us committing in writing something which we would not say to that person while looking into their eyes!
Freelance data scientist Nadieh Bremer will talk to us about visualizing data in Toronto. She has learned that meeting people face to face — or at least having a video call — is important. She told me:
“As a remote freelancer, I know that to interact well with my clients I really need to have a video call (stress on the video) I need to see their face and facial/body interactions and they need to see mine. For clients that I have within public transport distance, I used to travel there for a first ‘getting to know each other/see if we can do a project’ meeting, which would take loads of time. But I noticed for my clients abroad (that I can’t visit anyway) that a first client call (again, make sure it’s a video-call) works more than good enough.
It’s the perfect way to weed out the clients that need other skills that I can give, those that are looking for a cheap deal, and those where I just felt something wasn’t quite clicking or I’m not enthusiastic about the project after they’ve given me a better explanation. So these days I also ask my clients in the Netherlands, where I live, that might want to do a first meeting to have it online (and once we get on to an actual contract I can come by if it’s beneficial).”
Working In The Open
Working in the open (with the project frequently deployed to a staging server that everyone had access to see), helped to support an iterative approach to development. I found that it was important to support that live version with explanations and notes of what to look at and test and what was still half finished. If I just invited people to look at it without that information we would get lists of fixes to make to unfinished features, which is a waste of time for the person doing the reporting. However, a live staging version, plus notes in a collaboration tool such as Basecamp meant that we could deploy sections and post asking for feedback on specific things. This helped to keep everyone up to date and part of the project even if — as was often the case for designers in an agency — they had a number of other projects to work on.
There are collaboration tools to help designers to share their work too. Asking for recommendations on Twitter gave me suggestions for Zeplin, Invision, Figma, and Adobe XD. Showing work in progress to a developer can help them to catch things that might be tricky before they are signed off by the client. By sharing the goal behind a particular design feature within the team, a way forward can be devised that meets the goal without blowing the budget.
Scope Creep And Change Requests
The thing about working in the open is that people then start to have ideas (which should be a positive thing), however, most timescales and budgets are not infinite! This means you need to learn to deal with scope creep and change requests in a way that maintains a good working relationship.
We would often get requests for things that were trivial to implement with a message saying how sorry they were about this huge change and requests for incredibly time-consuming things with an assumption it would be quick. Someone who is not a specialist has no idea how long anything will take. Why should they? It is important to remember this rather than getting frustrated about the big changes that are being asked for. Have a conversation about the change, explain why it is more complex than it might appear, and try to work out whether this is a vital addition or change, or just a nice idea that someone has had.
If the change is not essential, then it may be enough to log it somewhere as a phase two request, demonstrating that it has been heard and won’t be forgotten. If the big change is still being requested, we would outline the time it would take and give options. This might mean dropping some other feature if a project has a fixed budget and tight deadline. If there was flexibility then we could outline the implications on both costs and end date.
With regard to costs and timescales, we learned early on to pad our project quotes in order that we could absorb some small changes without needing to increase costs or delay completion. This helped with the relationship between the agency and ourselves as they didn’t feel as if they were being constantly nickel and dimed. Small changes were expected as part of the process of development. I also never wrote these up in a quote as contingency, as a client would read that and think they should be able to get the project done without dipping into the contingency. I just added the time to the quote for the overall project. If the project ran smoothly and we didn’t need that time and money, then the client got a smaller bill. No one is ever unhappy about being invoiced for less than they expected!
This approach can work even for people working in-house. Adding some time to your estimates means that you can absorb small changes without needing to extend the timescales. It helps working relationships if you are someone who is able to say yes as often as possible.
This does require that you become adept at estimating timescales. This is a skill you can develop by logging your time to achieve your work, even if you don’t need to log your time for work purposes. While many of the things you design or develop will be unique, and seem impossible to estimate, by consistently logging your time you will generally find that your ballpark estimates become more accurate as you make yourself aware of how long things really take.
“It all comes down to respect for your colleague’s craft, and sort of knowing your place and precisely where you fit into the project. When working with a developer, I surrender to them in a creative way, and then, defuse whatever power play they might try to make on me by leading the charges with constructive design advice, lightning-fast email replies and generally keeping the spirit upbeat. It’s an odd offense to play. I’m not down with the adversarial stuff. I’m quick to remind them we are all in the same boat, and, who’s paying their paycheck. And that’s not me. It’s the client. I’ll forever be on their team, you know? We make the stuff for the client. Not just me. Not ‘my team’. We do it together. This simple methodology has always gone a long way for me.”
I love this, it underpins everything that this article discusses. Think back to any working relationship that has gone bad, how many of those involved you feeling as if the other person just didn’t understand your point of view or the things you believe are important? Most reasonable people understand that compromise has to be made, it is when it appears that your point of view is not considered that frustration sets in.
There are sometimes situations where a decision is being made, and your experience tells you it is going to result in a bad outcome for the project, yet you are overruled. On a few occasions, decisions were made that I believed so poor; I asked for the decision and our objection to it be put in writing, in order that we could not be held accountable for any bad outcome in future. This is not something you should feel the need to do often, however, it is quite powerful and sometimes results in the decision being reversed. An example would be of a client who keeps insisting on doing something that would cause an accessibility problem for a section of their potential audience. If explaining the issue does not help, and the client insists on continuing, ask for that decision in writing in order to document your professional advice.
Learning The Language
I recently had the chance to bring my CSS Layout Workshop not to my usual groups of front-end developers but instead to a group of UX designers. Many of the attendees were there not to improve their front-end development skills, but more to understand enough of how modern CSS Layout worked that they could have better conversations with the developers who built their designs. Many of them had also spent years being told that certain things were not possible on the web, but were realizing that the possibilities in CSS were changing through things like CSS Grid. They were learning some CSS not necessarily to become proficient in shipping it to production, but so they could share a common language with developers.
There are often debates on whether “designers should learn to code.” In reality, I think we all need to learn something of the language, skills, and priorities of the other people on our teams. As Aaron reminded us, we are all on the same team, we are making stuff together. Designers should learn something about code just as developers should also learn something of design. This gives us more of a shared language and understanding.
“I have basically made a career out of being both technical and creative so I strongly feel that the more crossover the better. Obviously what I do now is wonderfully free of the constraints of client work but even so, I do think that if you can blur those edges, it’s gonna be good for you. It’s why I speak at design conferences and encourage designers to play with creative coding, and I speak at tech conferences to persuade coders to improve their visual acuity. Also with creative coding. It’s good because not only do I get to work across both disciplines, but also I get to annoy both designers and coders in equal measure.”
I have found that introducing designers to browser DevTools (in particular the layout tools in Firefox and also to various code generators on the web) has been helpful. By being able to test ideas out without writing code, helps a designer who isn’t confident in writing code to have better conversations with their developer colleagues. Playing with tools such as gradient generators, clip-path or animation tools can also help designers see what is possible on the web today.
We are also seeing a number of tools that can help people create websites in a more visual way. Developers can sometimes turn their noses up about the code output of such tools, and it’s true they probably won’t be the best choice for the production code of a large project. However, they can be an excellent way for everyone to prototype ideas, without needing to write code. Those prototypes can then be turned into robust, permanent and scalable versions for production.
An important tip for developers is to refrain from commenting on the code quality of prototypes from members of the team who do not ship production code! Stick to what the prototype is showing as opposed to how it has been built.
A Practical Suggestion To Make Things Visual
Eva-Lotta Lamm will be speaking in Toronto about Sketching and perhaps unsurprisingly passed on practical tips for helping conversation by visualizing the problem to support a conversation.
Creating a shared picture of a problem or a solution is a simple but powerful tool to create understanding and make sure they everybody is talking about the same thing.
Visualizing a problem can reach from quick sketches on a whiteboard to more complex diagrams, like customer journey diagrams or service blueprints.
But even just spatially distributing words on a surface adds a valuable layer of meaning. Something as simple as arranging post-its on a whiteboard in different ways can help us to see relationships, notice patterns, find gaps and spot outliers or anomalies. If we add simple structural elements (like arrows, connectors, frames, and dividers) and some sketches into the mix, the relationships become even more obvious.
Visualising a problem creates context and builds a structural frame that future information, questions, and ideas can be added to in a ‘systematic’ way.
Visuals are great to support a conversation, especially when the conversation is ‘messy’ and several people involved.
When we visualize a conversation, we create an external memory of the content, that is visible to everybody and that can easily be referred back to. We don’t have to hold everything in our mind. This frees up space in everybody’s mind to think and talk about other things without the fear of forgetting something important. Visuals also give us something concrete to hold on to and to follow along while listening to complex or abstract information.
When we have a visual map, we can point to particular pieces of content — a simple but powerful way to make sure everybody is talking about the same thing. And when referring back to something discussed earlier, the map automatically reminds us of the context and the connections to surrounding topics.
When we sketch out a problem, a solution or an idea the way we see it (literally) changes. Every time we express a thought in a different medium, we are forced to shape it in a specific way, which allows us to observe and analyze it from different angles.
Visualising forces us to make decisions about a problem that words alone don’t. We have to decide where to place each element, decide on its shape, size, its boldness, and color. We have to decide what we sketch and what we write. All these decisions require a deeper understanding of the problem and make important questions surface fairly quickly.
All in all, supporting your collaboration by making it more visual works like a catalyst for faster and better understanding.
Working in this way is obviously easier if your team is working in the same room. For distributed teams and freelancers, there are alternatives to communicate in ways other than words, e.g. by making a quick Screencast to demonstrate an issue, or even sketching and photographing a diagram can be incredibly helpful. There are collaborative tools such as Milanote, Mural, and Niice; such tools can help with the process Eva-Lotta described even if people can’t be in the same room.
I’m very non-visual and have had to learn how useful these other methods of communication are to the people I work with. I have been guilty on many occasions of forgetting that just because I don’t personally find something useful, it is still helpful to other people. It is certainly a good idea to change how you are trying to communicate an idea if it becomes obvious that you are talking at cross-purposes.
Over To You
As with most things, there are many ways to work together. Even for remote teams, there is a range of tools which can help break down barriers to collaborating in a more visual way. However, no tool is able to fix problems caused by a lack of respect for the work of the rest of the team. A good relationship starts with the ability for all of us to take a step back from our strongly held opinions, listen to our colleagues, and learn to compromise. We can then choose tools and workflows which help to support that understanding that we are all on the same team, all trying to do a great job, and all have important viewpoints and experience to bring to the project.
I would love to hear your own experiences working together in the same room or remotely. What has worked well — or not worked at all! Tools, techniques, and lessons learned are all welcome in the comments. If you would be keen to see tutorials about specific tools or workflows mentioned here, perhaps add a suggestion to our User Suggestions board, too.
Traditional software developers have been hiding a secret from us in plain sight. It’s not even a disputed fact. It’s part of their business model.
It doesn’t matter if we’re talking about high-end enterprise software vendors or smaller software houses that write the tools that we all use day to day in our jobs or businesses. It’s right there front and center. Additional costs that they don’t hide and that we’ve become accustomed paying.
So what is this secret?
Well, a lot of traditional software vendors make more money from maintaining the software that they write than they do in the initial sale.
[TCO is] the cost to implement, operate, support & maintain or extend, and decommission an application.
Furthermore, this paper by Stanford university asserts that maintenance normally amounts to 60% to 90% of the TCO of a software product.
It’s worth letting that sink in for a minute. They make well over the initial purchase price by selling ongoing support and maintenance plans.
We Don’t Push Maintenance
The problem as I see it is that in the web development industry, web application maintenance isn’t something that we focus on. We might put it in our proposals because we like the idea of a monthly retainer, but they will likely cover simple housekeeping tasks or new feature requests.
It is not unheard of to hide essential upgrades and optimizations within our quotes for later iterations because we‘re not confident that the client will want to pay for the things that we see as essential improvements. We try and get them in through the back door. Or in other words, we are not open and transparent that, just like more traditional software, these applications need maintaining.
Regardless of the reasons why, it is becoming clear that we are storing up problems for the future. The software applications we’re building are here for the long-term. We need to be thinking like traditional software vendors. Our software will still be running for 10 or 15 years from now, and it should be kept well maintained.
So, how can we change this? How do we all as an industry ensure that our clients are protected so that things stay secure and up to date? Equally, how do we get to take a share of the maintenance pie?
Porting an application to a new server, interfacing with a different operating system, upgrading to a newer release, altering a tax table, or complying with new regulations—all necessitate application — maintenance. As a result, maintenance is focused on upgrading an application to ensure it remains productive and/or cost effective. The definition of application maintenance preferred by the focus group is — any modification of an application to correct faults; to improve performance; or to adapt the application to a changed environment or changed requirements. Thus, adding new functionality to an existing application (i.e., enhancement) is not, strictly speaking, considered maintenance.
In other words, maintenance is essential work that needs to be carried out on a software application so it can continue to reliably and securely function.
It is not adding new features. It is not checking log files or ensuring backups have ran (these are housekeeping tasks). It is working on the code and the underlying platform to ensure that things are up to date, that it performs as its users would expect and that the lights stay on.
Here are a few examples:
Technology and Platform Changes
Third-party libraries need updating. The underlying language requires an update, e.g. PHP 5.6 to PHP 7.1 Modern operating systems send out updates regularly. Keeping on top of this is maintenance and at times will also require changes to the code base as the old ways of doing certain things become deprecated.
As the application grows, there will be resource issues. Routines within the code that worked fine with 10,000 transactions per day struggle with 10,000 per hour. The application needs to be monitored, but also action needs to be taken when alerts are triggered.
Obvious but worth making explicit. The software has bugs, and they need fixing. Even if you include a small period of free bug fixes after shipping a project, at some point the client will need to start paying for these.
Hard To Sell?
Interestingly, when I discuss this with my peers, they feel that it is difficult to convince clients that they need maintenance. They are concerned that their clients don’t have the budget and they don’t want to come across as too expensive.
Well, here’s the thing: it’s actually a pretty easy sell. We’re dealing with business people, and we simply need to be talking to them about maintenance in commercial terms. Business people understand that assets require maintenance or they’ll become liabilities. It’s just another standard ongoing monthly overhead. A cost of doing business. We just need to be putting this in our proposals and making sure that we follow up on it.
An extremely effective method is to offer a retainer that incorporates maintenance at its core but also bundles a lot of extra value for the client, things like:
Reporting on progress vs. KPIs (e.g. traffic, conversions, search volumes)
Limited ‘free’ time each month for small tweaks to the site
Reporting on downtime, server updates or development work completed
Access to you or specific members of your team by phone to answer questions
Indeed, you can make the retainer save the client money and pay for itself. A good example of this would be a client’s requirement to get a simple report or export from the database each month for offline processing.
You could quote for a number of development days to build out a — probably more complex than initially assumed — reporting user interface or alternatively point the client to your retainer. Include within it a task each month for a developer to manually run a pre-set SQL query to manually provide the same data.
A trivial task for you or your team; lots of value to your client.
A Practical Example
You’ll, of course, have your own way of writing proposals but here are a couple of snippets from an example pitch.
In the section of your proposal where you might paint your vision for the future, you can add something about maintenance. Use this as an opportunity to plant the seed about forming a long-term relationship.
You are looking to minimize long-term risk.
You want to ensure that your application performs well, that it remains secure and that it is easy to work on.
You also understand how important maintenance is for any business asset.
Later on, in the deliverables section, you can add a part about maintenance either as a stand-alone option or bundled in with an ongoing retainer.
In the following example, we keep it simple and bundle it in with a pre-paid development retainer:
We strongly advocate that all clients consider maintenance to be an essential overhead for their website. Modern web applications require maintenance and just like your house or your car; you keep your asset maintained to reduce the tangible risk that they become liabilities later on.
As a client who is sensibly keen to keep on top of the application’s maintenance as well as getting new features added, we’d suggest N days per month (as a starting point) for general maintenance and development retainer.
We’d spread things out so that a developer is working on your system at least [some period per week/month] giving you the distinct advantage of having a developer able to switch to something more important should issues arise during the [same period]. Depending upon your priorities that time could all be spent on new feature work or divided with maintenance, it’s your call. We normally suggest a 75%/25% split between new features and important maintenance.
As previously mentioned, this is also a great opportunity to lump maintenance in with other value-added ongoing services like performance reporting, conducting housekeeping tasks like checking backups and maybe a monthly call to discuss progress and priorities.
What you’ll probably find is that after you land the work, the retainer is then not mentioned again. This is understandable as there is lots for you and your client to be considering at the beginning of a project, but as the project is wrapping up is a great time to re-introduce it as part of your project offboarding process.
Whether this is talking about phase 2 or simply introducing final invoices and handing over, remind them about maintenance. Remind them of ongoing training, reporting, and being available for support. Make the push for a retainer, remembering to talk in those same commercial terms: their new asset needs maintaining to stay shiny.
Can Maintenance Be Annoying?
A common misconception is that maintenance retainers can become an additional burden. The concern is that clients will be constantly ringing you up and asking for small tweaks as part of your retainer. This is a particular concern for smaller teams or solo consultants.
It is not usually the case, though. Maybe at the beginning, the client will have a list of snags that need working through, but this is par for the course; if you’re experienced, then you’re expecting it. These are easily managed by improving communication channels (use an issue tracker) and lumping all requests together, i.e, working on them in a single hit.
As the application matures, you’ll drop into a tick-over mode. This is where the retainer becomes particularly valuable to both parties. It obviously depends on how you’ve structured the retainer but from your perspective, you are striving to remind the client each month how valuable you are. You can send them your monthly report, tell them how you fixed a slowdown in that routine and that the server was patched for this week’s global OS exploit.
You were, of course, also available to work on a number of new requested features that were additionally chargeable. From your client’s perspective, they see that you are there, they see progress, and they get to remove “worry about the website” from their list. Clearly, ‘those clients’ do exist, though, so the most important thing is to get your retainer wording right and manage expectations accordingly.
If your client is expecting the moon on the stick for a low monthly fee, push back or renegotiate. Paying you to do — say — two hours maintenance and housekeeping per month in amongst providing a monthly report and other ancillary tasks is exactly that; it’s not a blank cheque to make lots of ad-hoc changes. Remind them what is included and what isn’t.
How Do We Make Maintenance Easier?
Finally, to ensure the best value for your clients and to make your life easier, use some of these tactics when building your applications.
Long-Term Support (LTS)
Use technology platforms with well documented LTS releases and upgrade paths.
Ongoing OS, language, framework and CMS upgrades should be expected and factored in for all projects so tracking an LTS version is a no-brainer.
Everything should be running on a supported version. Big alarm bells should be ringing if this is not the case.
Good Project Hygiene
Have maintenance tasks publicly in your feature backlog or issue tracking system and agree on priorities with your client. Don’t hide the maintenance tasks away.
Code level and functional tests allow you to keep an eye on particularly problematic code and will help when pulling modules out for refactoring.
Monitor the application and understand where the bottlenecks and errors are. Any issues can get added to the development backlog and prioritized accordingly.
Monitor support requests. Are end users providing you with useful feedback that could indicate maintenance requirements?
The Application Should Be Portable
Any developer should be able to get the system up and running easily locally — not just you! Use virtual servers or containers to ensure that development versions of the applications are identical to production.
The application should be well documented. At a minimum, the provisioning and deployment workflows and any special incantations required to deploy to live should be written down.
Maintenance Is A Genuine Win-Win
Maintenance is the work we need to do on an application so it can safely stand still. It is a standard business cost. On average 75% of the total cost of ownership over a software application’s lifetime.
As professionals, we have a duty of care to be educating our clients about maintenance from the outset. There is a huge opportunity here for additional income while providing tangible value to your clients. You get to keep an ongoing commercial relationship and will be the first person they turn to when they have new requirements.
Continuing to provide value through your retainer will build up trust with the client. You’ll get a platform to suggest enhancements or new features. Work that you have a great chance of winning. Your client reduces their lifetime costs, they reduce their risk, and they get to stop worrying about performance or security.
Do yourself, your client and our entire industry a favor: help make web application maintenance become more of a thing.
Software developers all over the world can benefit from an increased understanding of intellectual property (IP) laws and how those laws may affect their work. Software programs are often complex works that include both functional and artistic elements and may be covered by a variety of different types of IP laws. This can be very confusing for those who haven’t been taught about IP and can cause them to miss out on opportunities to protect their own work or to accidentally infringe on the work of another.
The purpose of this article is to provide information about one type of IP law, copyright law, for software developers who live or work in the United Kingdom. Below we will discuss the definition of copyright law, the source of UK copyright law, and how it applies to technological works. I’ll also elaborate on what is not covered by copyright law, as well as the UK concepts of fair dealing and moral rights as they are related to copyright law.
Copyright Law Essentials
You can learn more about copyright law in general and about how it applies to software in my previous article. Go to article →
What Is Copyright Law?
Copyright law is a type of intellectual property law that protects creative works, which can include things like plays, movies, drawings, songs, and many other things. Around the world, copyright laws give the authors or creators of literary, dramatic, musical, or artistic works the right to control the ways in which their material may be used. With regard to software, copyright law generally covers the artistic elements of a software program as opposed to the functional elements.
What Is The Source Of Copyright Law In The UK?
Copyright law originated in the United Kingdom from a concept of common law; the Statute of Anne 1709. It became statutory with the passing of the Copyright Act 1911. The current act is the Copyright, Designs and Patents Act of 1988. Those interested can read the full text here.
The relevant government office for copyright inquiries is the UK Intellectual Property Office. The UK is also a signatory to the Berne Convention, an international agreement concerning copyright law that has been adopted by 172 countries worldwide.
How Does UK Copyright Law Apply Specifically To Technological Works?
Copyright law can apply to all kinds of technological works that are used with computers, tablets, smartphones, or video game systems. This includes apps, computer programs, databases, spreadsheets, screen displays, and even virtual reality environments. Copyright also applies to works that are used or distributed on the internet like websites, blogs, and other online content. In the UK, computer programs are specifically protected as literary works.
Throughout the European Union, the Computer Programs Directive provides guidance regarding the legal protection of computer programs. The Copyright (Computer Programs) Regulations of 1992 extended the rules covering literary works to include computer programs in other European countries as well.
What Is Not Covered By UK Copyright Law?
Copyright law in the UK, as elsewhere, does not protect ideas, procedures, methods of operations, or mathematical concepts (though other types of IP may protect them under certain circumstances). In other words, copyright law is about protecting a particular expression of an idea, not the idea itself, and not functional elements of a work. Additionally, names, titles, short phrases, and colors are not generally considered unique or substantial enough to be covered by copyright law. However, a work that combines some of the elements, such as a logo or design, could possibly be eligible for copyright (and perhaps trademark) protection.
How Long Does Copyright Protection In The UK Last?
Because the UK is a signatory to the Berne Convention which covered this issue, a copyright in the UK will typically be protected for either the life of the author plus 70 years from the death of the author or, for published works, for 70 years from the date of first publication. However, there are many exceptions to this rule, and each work should be treated on a case-by-case basis if there are any doubts.
One notable UK-specific exception has to do with the boy who never grew up, Peter Pan. Author J.M. Barrie gifted all of the rights to his creation to a children’s hospital in London. When the original copyright expired in 1987, an extension was added to the Copyright, Designs and Patents Act of 1988 mentioned above so that the hospital could continue to collect royalties based on uses of the work (though the hospital has no creative control over how the work is used). Ultimately, this is only an unusual — and perhaps endearingly British — exception to the normal copyright term.
What Is Fair Dealing?
The copyright laws of almost all countries allow exceptions for certain permitted uses of copyrighted works such as news reporting, educational uses, or where the use of the work is de minimus. In the United States, one can assert a “fair use” defense if accused of infringing a copyright if the use was due to one of these permitted activities. In the UK, these permitted activities fall under the legal concept known as “fair dealing.” According to the University of Nottingham, eligible activities which can be conducted without infringing a copyrighted work include:
Private and research study purposes;
Performance, copies or lending for educational purposes;
Criticism and news reporting;
Copies and lending by librarians;
Format shifting or back up of a work you own for personal use;
Caricature, parody or pastiche;
Acts for the purposes of royal commissions, statutory enquiries, judicial proceedings and parliamentary purposes;
Recording of broadcasts for the purposes of listening to or viewing at a more convenient time;
Producing a back-up copy for personal use of a computer program.
How Does “Fair Dealing” Affect Technology Copyrights In The UK?
The “fair dealing” exceptions mentioned above may specifically impact copyrights for technology-related works such as software programs or databases. For example, producing a backup copy of a software program for personal use only would not be considered copyright infringement under a fair dealing exception. Though fair dealing explicitly excludes decompilation or copying a software program during decompilation, the European Software Directive allows software licensees to use their copy of the software “to observe study or test the functioning of the program” in order to “determine the ideas and principles which underlie any element of the program.”
Therefore, users may freely observe a program as it operates to determine their functions and its underlying ideas, even if the goal is to create a competing program (see the UK case SAS Institute v. World Programming for more information on this concept). However, actual copying, for example in the case of source code copying, is not tolerated since this is explicitly protected by copyright.
For practical reasons, database copyrights would not be infringed if a person with the legal right to use part or all of a database performs steps necessary to use or access the contents of the database. Also, accessing a database for the purposes of private study or non-commercial research does not infringe copyright in a database.
Moral Rights In The UK
Another difference between the UK and other parts of the world with regard to copyright law is the UK’s emphasis on the importance of moral rights. Though this issue may not often arise in technology-related copyright disputes, moral rights are additional rights over and above the economic rights typically protected by copyright law.
In the UK, moral rights are: the right to attribution, or the right to be known or recognized as the author of a work; the right to object to derogatory treatment of a work, which includes any addition, deletion, or adaptation of a work that would distort or “mutilate” the work or injure the honor or reputation of the author; the right to object to false attribution, which basically means that you would not be named as the author of something you didn’t create; and the right to privacy of certain photographs and recordings, such as those commissioned for a private occasion.
One reason moral rights might be important for developers is that the moral right to attribution gives the developer the right to be named as the author of the software program, even though it is not common industry practice to do so. By the same token, if a developer doesn’t get their name associated with projects they didn’t work on, the right to object to false attribution protects them also. Find more information about moral rights here.
It is our hope that this information has been helpful for UK software designers and developers. Though this is only introductory information, and should not be substituted for legal counsel in the event of specific questions or disputes, education about copyright law issues and other IP issues helps to empower software designers and developers to make sure their works are fully protected.
At some point in your career, most web designers and developers can relate to issues with scope creep, unexpected project delays, client relationships breaking down, and unpaid invoices. The good news is that there’s an insurance policy to help with these scenarios. In the UK, we call it “professional indemnity insurance.” Elsewhere, it can be called “professional liability” or “errors and omissions insurance.”
Let’s explore what this insurance is and how it’s designed to keep web professionals in business. I’ll also be sharing real stories of businesses who were glad they had insurance.
What Is Professional Indemnity Insurance?
Professional indemnity insurance protects your business from screw-ups and problem clients.
Let’s say a client threatens legal action, claims loss of income or damages due to a service you provided. Even if you’re in the wrong, professional indemnity steps in to ensure the consequences to your business aren’t crippling.
It’s also important to distinguish what professional indemnity insurance isn’t. After all, business insurance is an umbrella term for different types of cover. One of those covers is public liability insurance — or general liability insurance as it’s known in the US.
Public liability insures your business against claims of:
physical injury to clients and members of the public
accidents on your work premises
damage to third-party property.
This is a popular cover for those who have clients visit their office or those who work from client premises. However, in this article, we’re focusing exclusively on professional indemnity.
How Can Insurance Help Me If I’m A Designer Or Developer?
Business insurance isn’t often talked about in web circles. I think it’s because insurers have focused their products and user experience on traditional industries. A lot of the information out there isn’t relevant to those of us working in digital.
To add to that, people don’t equate working with a computer as being a danger or massive liability. Especially when you have all of your clients sign a contract. This can lull designers and developers into a false sense of security. A common objection I hear from web professionals when talking about insurance is:
I can’t cause any damage as a web designer. For anything that does go wrong, I have a clause in my contract that says I’m not liable.
Firstly, I have to debunk the myth of not needing to have insurance because you work with a contract. Contracts don’t alleviate you from liability. They’re useful for laying the foundation of what duties are expected of both parties, but insurance steps into action when those duties come into question.
With every scenario I’m sharing today, they all had the following in common:
A contract was signed by both parties.
They had years of experience in their profession.
They were professionally insured, but never expected to have to use their insurance.
Below are real stories of how professional indemnity insurance helped these designers and developers.
A developer built a web platform to spec, but the client complained of missing functionality.
The developer agreed to build the perceived missing functionality for a further fee, but the client believed it should have been included in the initial build. Not only did the client refuse to pay the remaining invoice, but they threatened legal action if the developer didn’t cooperate.
Having professional indemnity insurance meant that the developer had a team of legal experts behind him. They helped the developer communicate with his client to avoid the problem escalating.
The developer’s professional indemnity policy also had a mitigation costs clause. This meant the insurer paid the amount owed to him by his client, which was thousands of pounds.
Designers and developers often work to tight deadlines. Missing deadlines can cause problems if the project has an important launch date.
A creative agency was hired to design a website, but the project started to unravel. Key members of the team left part way through the project and the pace of the work being completed slowed down.
While the website was delivered in time for launch, it was missing a lot of major features. The client said it wasn’t fit for purpose.
After wasting money on a marketing campaign for the launch, the client refused to pay the final invoice. They also incurred extra expenses from hiring new contractors to complete the website’s missing features.
The client threatened to involve solicitors if the agency pursued payment.
The unpaid invoice was settled by the insurer under the mitigation costs clause of their professional indemnity policy. The insurer also provided the agency with legal advisors to confirm with the client that the project is considered at an end.
Client Relationships Breaking Down
This is a common catalyst for professional indemnity claims. Even if we spot a few amber flags, we like to believe we can make our client relationships work and projects run smoothly. However scary it is, sometimes you have to burn bridges with a client.
A designer did this when working with a client they felt didn’t respect them. An ever-changing scope, long hours, and poor pay lead to a breakdown in the relationship. What had started off as a promising project was now a strained working relationship and source of stress. The designer decided to walk away from the project.
Unfortunately, that wasn’t the end of things. The client wanted to be reimbursed for the money they had already paid to the designer. They also wanted damages for the loss of income due to a delayed launch and compensation for hiring other contractors to complete the project.
A team of legal experts was arranged by the insurer to deal with the designer’s client. A settlement was agreed out of court, which was also covered by the insurer.
What Does A Professional Indemnity Policy Insure Against?
Professional indemnity insurance is a meaty policy, so it isn’t feasible to cover every scenario here. At its core, it’s designed to put your business back in the same financial position after a loss as it was in before a loss. As you can see from the stories above, a loss can be legal fees, client damages, compensation or even unpaid invoices. However, this has to stem from a client expressing dissatisfaction with your work.
While all professional indemnity policies differ, let’s look at some of the key features you can expect to see.
If a client makes a claim against you, your professional indemnity policy will pay the defence costs. This isn’t just for situations that have escalated to court. Insurers want to solve problems before they get to that stage, so they’ll provide a team of legal experts to help negotiate terms with your client.
Intellectual Property Infringement
Web and graphic designers are vulnerable to arguments over copyright infringement, whereas developers could get into disputes over who owns the code. This clause covers claims against copyright infringement, trademarks, slogans, and even domain names.
If you read the stories above, you’ll have seen mitigation costs mentioned where unpaid invoices were paid by the insurer. If a client is dissatisfied with your work, refuses to pay any or all your fees and threatens to bring a claim against you, professional indemnity may pay the amount owed to you by your client. This is only if the insurer believes it will avoid a claim for a greater amount.
Negligence covers a broad spectrum, but think of this as a warranty for any mistakes you make that lead to an unhappy client.
Unintentional Breach Of Contract
Breach of contract can take many forms. It could be something as simple as failing to deliver a project on time or not meeting the client’s expectations. Any breach of contract may entitle the client to make a claim against you.
Some Practical Tips For Buying Insurance
The first question people ask when it comes to buying insurance is, “How much should I insure my business for?”. The level of cover will typically start at £100,000 and can go well into the millions. It can be a difficult question to answer, but there are factors that can help you arrive at a reasonable figure.
If your client contract has an insurance clause, it’s usually for £1,000,000 of professional indemnity. This is the base level of cover a client would expect. It’s the most common level of cover I see businesses buy.
Types of Clients
What type of clients are you working with? Is it large corporations with in-house legal teams, or local small businesses? It’s not unwise to assume the larger companies pose a bigger threat, therefore should have a higher level of cover. You may also find that larger companies will have an insurance clause in their contract.
Type Of Work You Do
A developer building a payment platform will potentially face a bigger risk than somebody designing a website to showcase a restaurant’s menu. Does your work involve dealing with sensitive information or higher-cost products? Are businesses depending on your service to generate income for them?
If it feels like I’ve skirted around answering this, it’s because there isn’t a straightforward figure. A lot of insurers will simply tell you to buy what you’ve budgeted for. If in doubt, consider a base level of £1,000,000 and periodically evaluate your clients and type of work you do. Most insurers allow you to make a mid-term adjustment part way through your policy to increase your level of cover.
Other than the cost of insurance, there are a few other factors to be aware of when buying insurance.
Insuring More Than One Activity
The web is a multi-disciplinary industry. You should be looking for a policy that can cover your various activities. A web developer may also provide web hosting. A designer may also offer consulting services. If you fall outside of the typical box, you might find it useful talking to a broker or using a service like With Jack where your policy can be customized instead of using an online comparison site.
Insuring Your Work Worldwide
By default, professional indemnity policies in the UK exclude US jurisdiction. If you’re working with US clients under US contract law, look for an insurer that can lift the jurisdictional limit from your policy, so you’re insured worldwide. Just beware that it will increase your premium.
Your Policy Can Adapt To Your Needs
Insurance can be flexible. Don’t delay buying insurance because you’re thinking of switching from sole trader to Limited company down the line, or because you’re waiting to add a new service to your business. A good insurance company will allow you to adjust your policy, adapting it as your business changes and grows.
How Insurance Can Help You Build A Bulletproof Business
Whenever I see newcomers ask for advice on starting their business in the web industry, I see a lot of suggestions that look like this:
“Get an accountant immediately.”
“Build a network!”
“Have your clients sign a contract.”
“Monitor your cashflow!”
This is all great advice, of course, but rarely do I see anybody mentioning getting insured. Insurance should be a crucial part of any professional designer or developer’s toolbox.
Offering your professional services to clients comes with a degree of risk. It’s your responsibility to mitigate that risk. You have to be confident that — if something does go wrong — you can get back to work quickly. There can be issues with mistakes in your work, a relationship going sour or a client claiming they’re unhappy with your service. It doesn’t matter how good you are, these things happen!
This is why I’m sharing these stories — to highlight the importance of being insured. I want to get web professionals not just thinking about insurance, but understanding it. Insurance is something we don’t necessarily want to budget for or consider, yet as professionals, we have to. The stories above show how critical it can be.
So yes, work with a contract. Monitor your cash flow. Have an accountant manage your bookkeeping, but also get insured. There’s little point in building your business only for one problem client or mistake to take it away from you.
When high potential projects fall apart, it’s often a failure of collaboration and alignment. The tools, the assumptions, the opportunity, and the intentions may line up, but if people don’t communicate or don’t have a clear map to help them move in the same direction, even the best projects falter.
Communication failures are human problems, so they’re messy and hard to solve. They involve feelings and a willingness to have uncomfortable conversations.
We know that there’s a lot of optimizations that we can use to improve the performance of our images – but does this work really translate into wins for your company? In this talk, Allison McKnight, performance engineer at Etsy, will share real-world examples of the positive impact that image optimizations can have on metrics that your bosses and clients care about. You will walk away from this talk with compelling data and useful tools to help you get buy-in and support for this important user experience work at your company.
The beginning of a new year seems like a perfect time to think about what we web professionals do, why we do it, how we could do it better and even how we could have more fun doing it.
Like everyone, we learn lessons as we make our way through life and work. If we’re lucky, we pick up some good advice along the way, so we thought it might be useful to find out what kind of advice you all have found to be particularly valuable.
Productivity tips always make for a popular topic for an article, as everyone is looking for the silver bullet, that one weird trick that turns you into a productivity machine. However, the tips that work well for one person may not work so well for another.
We asked the community on Twitter and Facebook to share their best productivity tips, and in this article I’m going to round these up alongside some things I’ve learned that work well for me.
Designing at your desk with Photoshop or HTML and CSS is easy, but getting your bosses and clients to give your work their stamp of approval is often quite a feat. In this webinar, Dan will share some stories of tools, methodologies, and non-traditional deliverables that can help you get the buy-in you need. Follow along to learn how to make everyone you work with say “please” and “thank you!”