Selling Digital by the Hour is Like Shooting Yourself in the Foot Before Going For a Run

Why everyone wins when we bid the time-based market farewell

Good morning! Another new week and time to package a deal for a new client. As usual, you load the small-caliber pistol and shoot yourself in the foot since the only money you earn is from being slow—wouldn’t want to go too fast and lose out on that sweet money!💰 Prepared as you always are, you’ve already stacked up on band-aids to manage the bleeding (or incrementally losing resources) so you don’t die and–as a natural consequence–go out of business. With a fistful of paracetamol in the jacket pocket to lighten the pain, you are ready to rock! 🤘

A while back, I heard a question being posed which I wasn’t quite prepared for at the time. I was demoing Figmagic, a tool to improve designer-developer handoff. Using it, our team would certainly cut project/dev time with a great deal. A normal handoff scenario would go from potentially hours to somewhere between a few seconds and maybe 10 minutes, depending on the complexity and manual interfacing between people. The problem frame in which Figmagic comes in is that handoffs usually take lots of time; by their nature they’re based around double the work for a given unit of finished product; and that design and code are notoriously hard to sync and get right between all involved. We want to increase product quality while reducing production time, yet increasing the psycho-social satisfaction between all of us who work together.

So, for those words:

”Our business model is in selling hours. Wouldn’t this undercut that model?”

First and foremost I highly doubt that such a model is actually—really—used, if only because it would be suicidal: “selling hours” is effectively removing the customer value perspective from the question. In that case one is thinking time rather than process (understanding, learning, improving…) and product (quality, delivery…). Numerical measurements become more important than what to do with them, and what they should amount to. What gives? 🤷‍♂️

New ways of working change business models

Assuming that the “relentless progress of time” grants new and better ways of working, as well as the requisite tools, we could further deduce that the effort to make a project X is consequently diminishing for each year. This obviously requires that one adapts and implements such new tools and processes. At the same time, lots of things do stay linear or near-linear in time and effort, like client communication, stakeholder management, planning and so forth. Management consultants being what they are, they seem to still be able to capitalize on this fact of management being required to this day. Does this then mean that a new project in 2018 will receive a smaller budget, with a management slice the same size as yester-year but the production part becoming ever smaller?

Let’s think about the context.

1. Someone is always already trying to outrace you when it comes to production optimization because optimum revenue is the thing that happens when you make big money from zero work. Meaning, a bit more diplomatically, that the least amount of work, and quickest way of working, will translate into the biggest amount of cash money given an efficient (cheap) and an inefficient (expensive) competitor—if we are entirely assuming time-based market pricing. This can rapidly devolve into a race-to-the-bottom scenario.
2. Holding on to less efficient ways of working can absolutely be both sign and symptom of other troubling issues: friction in the team, frequent misunderstandings, failed delivery deadlines… Tools and processes are extremely valuable and entirely controllable, which people are not (unless your managerial idol is Satan).

3. Conventional thinking seems to place client and service provider as inherently oppositional. This manifests in verbiage, tugs-of-war and various ideas of how to maximize the deal from either end. The end-user is, in this context, very far away. It all reeks of patriarchal old-mans business from the 19th Century or plain good old robber barons.

There is a set of very different values guiding our work at Humblebee.

1. Make time to evolve. Optimizing production (and anything else, really) should increase or move time towards other aspects of the project: to support learning, skill-building, better and more complex productions and to gain a higher foothold as a company. We want to always be evolving and challenged, not dumbed-down! This creates clear incentives for employees/colleagues as well as the client, who can buy better and more mature work.
2. Focus, open up, and improve way-of-working. By tightening processes and tools, and letting these be co-owned and co-created by employees, we create internal interest, knowledge and a sense of pride and ownership of how we work and who we want to be.
3. Equal relations. We believe in symbiotic relations with clients. We want them to naturally turn to us, and want our staff to be eager to make new superb work for the clients. The relationship should be driven by deep, sincere concern from both parties toward each other. In effect, this is very close to how any close relation functions. Anything oppositional needs to be ironed-out and analyzed to see how we can improve in our offering, communication or business. All of our staff is engaged in at least one of these areas, so taking a learning and applying it has a very short turnaround time.

Can’t get everything

While I was at Sogeti, one very basic thing I learned early on was the price-quality-speed triangle. Early in the planning/scoping phase, clients would point where they saw their project exist in such a matrix. This provides a quick, but illustrative idea of what factor(s) will be more (or less) important. The model provides well-needed tension between depth/time and quality, as well as removing the idea of every single factor being done to perfection on a shoestring budget in a day or two of work. Any discussions would fall back on this shared, initial understanding if there was confusion or need for direction.

For example, when it comes to the web today, my feeling is that quality is always severely deprioritized. My developer side wants to believe that the web is a ”solved problem” by now. Compared to fields like AR/VR/MR, neuro-cognitive tech, complex realtime graphics, physical computing etc. the web is a technologically fast-moving but medium-wise slow, mature medium. It’s hardly the wild west anymore. There are numerous best practices and a solid base for the medium to stand on. Yet, both big and small clients’ sites are poor in UX, security, performance, accessibility and so forth. And they don’t want to invest. Yet they spent significant money on their digital presence. No doubt there is a bit of mismanaged vanity projects out there, but I just don’t believe they are all made of such poor material.

For me this issue is a conundrum. Where does that money go? What does it buy you? Does the client know about deficits? Why does a client trust a doctor saying that one suffers from a disease one does not know even ailed oneself, but not experts who point out flaws in their digital assets? Maybe every one is a designer and developer ;)

This often ends in clients wanting a product (or site, or service) produced in a short amount of time according to a spec. The problem is that as projects and visions become more integrated into the client’s entire business offering or brand-new business models, one can no longer simply plop-produce something.

Production vs creation

These lines of thinking, I believe, stem from an understanding of products/services as being produced rather than created. With “produced”, the emphasis is placed on the concept of a vendor—a kind of basic production facility—churning out breadboxes, cereal or any of the trinkets you might find on Alibaba or Wish. Being a vendor is to be a black box that outputs something, cheaply, painlessly and sort of magically. This is raw Fordist capitalism with absolutely no external insight into the process: the way you might buy production time and materials for a quarter-million beer bottles with printed stickers on them. As customers, we just hope, believe, and expect whatever comes out the other end to be the right thing. Which it often isn’t, when buying something complex, like design services. A modern service or product is not the same as a package of cereal. Yet the above logic is bizarrely added onto design services.

Buying a designed product or service is kind of an intimate thing. There needs to be a connection and understanding happening between the actors, who themselves pretty much always consist of relatively large groups of people. Further, the expertise that is expected in a service delivery include knowing well ahead of time what the product/service should be in the first place. That stuff is slippery, fluid and complex. A new product or service must be gestated and created through a process that has a much greater range of uncertainties, from audience, viability, scope, implementation, and so on. Competencies and skills from a wide range of people is required, and no one can be the singular master of the entirety. The customer is not right—but neither is the service provider (design studio). They need to be collaborating or it’s just a massive burnout waiting to happen.

More and more clients are warming up to this notion, and are slowly becoming somewhat fluent in being a buyer. Note: from a UX perspective, buying these services often suck! This is something all of us working in tech should seriously consider. Of course this becomes deeply ironic since what we create must not be poor from a UX standpoint.

How do we begin changing the rulebook?

Depends on who you are. As a Technical Designer, my main contribution has been to optimize bulk operations. Figure out what holds great work back, and then just do it.

But who am I optimizing for, really? Me? My team? The client team? The broad, sketchy economic interests of my company ? …The client company?! Is the choice of a certain provider a vanity thing (like buying design by Pentagram could be for some) more than a mature design/business decision? Are we simply trying to lean ourselves to death? Nope. This is all done in order to get to where we really want to be. This is what should guide optimization work, lest we derail into discussions about robots taking our jobs. At Humblebee, optimization of the technical platforms and ways-of-working means developers can get into the game quicker.

Being on the ball early gives our team certain benefits, like more time for ideation, validation, real-life UX, exposing realistic opportunities for meaningful iteration, as well as opening new venues for experimentation and possible (contained) failure, like trying new stuff, using a radically different approach... We can do this in lockstep by having a tight relationship between developers, designers and product owners from day one, as my colleague Paul Aston has written about previously.

Some of the bigger, practical things we’ve done to cut bulk project time involve:

• Creating reusable code (boilerplates, base repos…) to drastically cut back on start-up time.
• Choosing state-of-the-art technologies which are also extremely fast – NodeJS and JavaScript as our base tech.
• Having strong opinions on types of project technology, architecture and infrastructure — meaning we also know when to say ‘no’.
• Actively forming an internal company culture that aims to deeply integrate designers and developers, and spending time working together in cross-disciplinary teams (no-one flying solo as a “kamikaze consultant”).
• Creating in-house processes and tools to work faster and deliver with ever-higher quality.
• Teaching best practices to onboard colleagues fast and using peer-learning techniques to continuously offload each other from being the sole “teacher guy/girl”.
• Dedicating time to exchange ideas, learning together and doing retrospectives.

Projects effectively transform from blackboxed input-output products into truly two-way, living processes. All the talk of co-creation in the world means nothing if the team and project cannot concisely respond in real-time.

The ironic twist: Using time to our advantage

The key constraint in Humblebee’s own price-time-quality triangle is ideally always–only–time: because time is what we are absolutely boss about. Choosing your strongest skill as the critical boundary means you can take charge like never before. We are moving to a model we call the 60 day MVP which creates a strict frame of three working months, meaning we plan entirely within that limit. Since we are constantly optimizing how we work, we can deliver prototypes and working versions in very little time, iterating on them as we move along in an agile manner. Thus, 60 days which could be suffocating for another studio gives us a clear line of sight for the final product. Quality is the only remaining factor of the three from the price-quality-speed triangle. Because the scope is most often an MVP (Minimum Viable Product) the bar is already set relatively low to what we are used to from other contexts. This means that the quality we provide will most likely be far above what is expected. Ultimately this equates to remarkable performance seen as a whole. For the client, this is all wrapped in a package deal making it very easy to glean business value and a concrete end-of-the-day outcome, while still staying open to agile project changes and having room for meaningful UX work.

The value we add is much more than there simply being just a digital product or service in the client’s and user’s hands (or environment, or head, or whatever). That’s an absolute requirement, not a feature! The essence of this way of working means that we have a skilled, cross-functional team that truly can work along with business decisions and any preliminary work. Products don’t sit waiting for any perfect, immaculate conception to occur. We’re all in it from day zero.

Outro: The do’s and don’ts

• Don’t: Commit to a race to the bottom.
• Do: Use time (coarsely) as measurement of project scope. For us, we are currently setting the target for what we call the 60 day MVP as a base working model.
• Don’t: Stick to old/slow/poor/counter-productive patterns, tools, processes or methods.
• Do: Use as few and as transparent processes as possible since processes won’t usually be what puts money in your account. Learn to use the current state-of-the-art and commit to staying on top (on company time, of course).
• Don’t: Aim for the magic, epic reveal.
• Do: Do what you need to produce fast and iterate in an agile manner and keep people in the loop. Others aim for weekly meetings as a minimal solution—we aim for always-on tools that allow feedback and insight anytime, anywhere but without any fixed meetings to discourage toxic meeting culture with the all-too familiar paper products.

At Humblebee, our core idea is to deliver the right thing, and fast, to boot. We’ve done a bunch of projects in neck-breaking speed. For such speed to create leverage for us—and for the client—it needs to be packaged and done right. We are super-happy with this way of working and have been moving in this direction for some time and are right in the middle of going all-out with this.

I hope this gave some insight into how we are dealing with the changing climate of working with digital products and services in 2018 and forward!

Mikael Vesavuori is a Technical Designer at Humblebee, a digital product and service studio based in Gothenburg, Sweden. Humblebee has worked with clients such as Volvo (Cars, Trucks, Construction Equipment), Hultafors Group, SKF, Mölnlycke Health Care, and Stena. Our design sprint-based approach and cutting-edge technical platform lets us build what’s needed.