Making Digital Products

Created at:

Ever since I started blindly copy-pasting code snippets in my first Invisionize forum, 15 years ago, I’ve always wondered how digital products are made. Working as an ASP developer, a front end developer, a UI engineer, and a web designer I managed to get some answers to the “how” part of the question but the more I learnt, the more I became aware of the great amount of work that has to go in the “why” and “what” part of the Work. The latter pushed me to pursue a career in Product Management.

In this article I try to write down some thoughts that I have gathered in these 15 years of working with digital products and, more specifically, those intense last 5 years in Berlin.

Not necessarily to share knowledge with others (though it would be great if anyone benefited from this) but mostly so that I don’t forget all these before my sleep-deprived family life with two children wipe them out faster than a neuralyzer.

The splitting of the content happens, for now, between two important chapters of my learning path:

  • Building the product right.

  • Building the right product.

This is, and will always be, a working draft so I will keep some personal ToDos in the content.

Build the product right.

Ever since I’ve received a paycheck to write or design code, I’ve always been part of two main discussions around the “how” to build products: Speed and Quality. So, I’m going to focus on these.

Speed

Otherwise, “how fast to deploy to production” though some smart people would better argue “how fast to customer value”. Either way, let’s start with the first rule of improving speed within a team: don’t start by trying to improve speed.

When you tell a creator (terms that will include both designers and engineers from now on) that you need to work on velocity it gives the impression that they are not already going fast enough. Which they, understandably, interpret as “they are not trying hard enough” which in our knowledge industry could be the most demotivating thing one can hear, even if it’s true.

Instead, start with the assumption that everyone does the best they can do within their own skills and environment, and then focus on improving these two.

Skills and training

It goes without saying that you need to hire for people who have the skills you need already.

If they don’t or outside factors have made them obsolete (which is about every 3 weeks for a JS developer), then training seems to be the obvious path. Options are plenty: conferences, books, side projects or trying out new things at core projects but the important factor of success here is not the type of curriculum but the surrounding trust.

Trust in them in that they are doing their best to achieve their goal and trust in you in that you are providing clear goals coupled with the necessary space and patience from your side. The moment they feel that you are de-prioritizing their learning path against some product work they will become demotivated and give up.

The “you” here could be a product manager or CTO in small organizations, or a senior developer or engineer/design manager in larger ones but, ideally, the person should be their line manager so that this effort is also reflected in performance reviews/salary adjustments. These goals should be set via clear OKRs for which you would check their progress on your weekly 1:1s.

Environment – Process

I already touched upon the big topic of trust which might, actually, seem to better fit under this category. The other big influencing factor of Speed is Process which dictates the various aspects of workflows of getting personal or team work into production with the best possible quality.

On a personal level, I believe that the most helpful tool for achieving high quality of work is a simple checklist, either implicit (mental) or explicit (written), of things you need to do in order to move a deliverable to the next stage of production (like ask for peer review, test, raise flag, deploy to production). This is perhaps the only part where I allow strict accountability as the process of following a process or not falls almost exclusively on a personal level of responsibility. If there are external factors that prevent someone from doing so, I expect to be informed of these so that I can help them or personally take action to overcome this impediment.

On a team level, the boundaries of accountability blur and upkeep of quality becomes a team game. Considering that everyone is doing their best personal work already, it’s easy to detect the source of defects in the cracks between the different stages: a designer’s specs are not well understood by the developer, a piece of deployed code that breaks other untested parts of the application and a delivered functionality is never checked if it fulfills the acceptance criteria by the business stakeholder. The more steps are in a serialized process, the higher the risk of introducing defects. Similarly, the more time is spent in building software the greatest the danger of releasing functionality that is obsolete due to changing environment factors–this in the rare case you are building the right solution from the start. If, as in most cases, you are building the wrong thing then you learn that you are wrong after a lot of time.

This is why iterative and collaborative development processes like Agile and its much controversial offspring, Scrum, have found wide adoption in organizations. Colocating, physically or virtually, the different team members by the introduction of frequent rituals like daily stand ups, sprint reviews, and plannings aims to reduce these feedback loops between team members and their targeted users. Communication, thus, is a very important factor of closing these loops and again, trust, is the most important ingredient in order for this to happen honestly, clearly and efficiently.

Quality

I define Quality by the perspective of defects, which in software are simply the bugs that are discovered after a piece of work is declared done, and the perspective of success, which could range from solving an existing defect to changing the behavior patterns of a specific user in order to achieve business success.

(ToDo: add piece about Jeff Sussna’s definition of quality: A responsive service organization is thus one with the capacity to continuously redesign itself based on internal and external empathy. )

(ToDo: Design quality)

Some Practical Tips

These are some tips to offer on the topic of building the thing right. I’ll work on breaking them down to expanded content and maybe provide some theoretical footing below them (some points themselves would serve as starting points for entire articles):

  • Collocate as much as possible. If you can’t, try to establish a good remote culture. Good audio quality in calls, detailed documentation of progress in work items, professionalism in remote setups are some non negotiable traits of a remote team. Here’s a great book on Remote work.

  • Never skip retros and always assign actionable items with accountable people.

  • Use design systems to minimize “design bugs” coming out of inconsistencies of growing systems. Live component systems are a great tool to automatically extend this quality in code.

  • Always test code. This is the only safe way to increase trust in a large codebase. Without trust you can’t scale your operations and will always be a slave to your codebase.

  • Always be integrating. Continuous deployment and continuous delivery enable everyone to push code to production with confidence at any point of time.

  • QA is not a person. It is a set of tools like the above that a developer uses in order to make sure that quality is met. If there is a person with this role, she functions as a coach and not an individual contributor. Simply put, a QA person doesn’t test code, she makes sure developers do and that they have the tools and knowledge to do that.

  • Definition of quality is a group effort led by this QA person and the PM and it is always evolving. This results in a list of Non Functional Requirements or a Definition of Done, which needs to be religiously followed before a work item is declared done.

  • Quality in design means: accessible, responsive, progressively enhanced interfaces. (Read https://resilientwebdesign.com )

  • Quality in code means zero bugs after delivery of a feature. Bugs are behavior of the product that is different than the defined specs (ranging from the high level acceptance criteria to the detailed results of the UX collaboration between designers and devs) of the work item or unintentionally inconsistent from the rest of the app.

  • Quality as a team means that the holistically delivered work solves-or brings the team closer to its solution-a business problem. While the formulation of a user story is not in itself a solution to user-centeredness, the mention of the actor and the reason of the feature request (“As a use I want to do something so that I can achieve something”)  and, more importantly, the consequent discussion between the group that leads to a common understanding of what need to be built and why, are very close to the heart of success of Scrum.

  • Visualize and reduce lead time.

To summarize, by cultivating talent, increasing trust, working in quality and closing feedback loops we will not inherently improve the speed by which a specific contributor produces work, but by eliminating the less visible sources of quality degradation we will eventually achieve greater team velocity. Not from start of code to deployment to production but from inception of idea to actually solving it. Which leads us to the next chapter, that of solving the right product.

Build the right product.

This is the responsibility and accountability of a Product Manager: to discover a valuable, usable, feasible Product. This is the definition of a Product Manager as provided by Marty Cagan in his book, Inspired, and I still find to agree with this simple definition.

A Valuable Product

Solves a business problem. Research user needs, market trends, find opportunities and consult product vision to come up with idea. Prototype to validate that this idea stands and is desirable by customers.

Usable

Collaborate with designers on making it usable. Prototype, test and prototype to get this right.

Feasible

Include engineers as early as possible to get technical feedback on the complexity of an idea or any red flags that could be hiding (this is my best xkcd comic on the hidden complexity of seemingly simple specs https://xkcd.com/1425/).

Process - The double diamond

This was introduced to me at Contentful by these two wonderful gentlemen: https://www.designcouncil.org.uk/news-opinion/design-process-what-double-diamond

It defines the relationship between the four steps of the design process, which could also account for the actual product development.

Discover (diverge)

This is an initial exploration phase of a problem or opportunity. The trigger for kicking this off is the recognition of a pattern of problems surrounding a common business or product area or an opportunity. This is a phase that a PM and other team members like researcher, designer or tech lead can drive while the feature team is delivering a feature. Exploratory customer interviews, competitive analysis, in-house workshops with colleagues are some of the ways that you can gain more context and information around a problem. The point of this phase is to have a lot of problems or a very big one.

Define (converge)

The same people can participate in this synthesizing phase where all this collected knowledge is mapped to a system in order to:

  • make some sense of it

  • emerge priorities from it

Such systems could be journeys, jobs to be done, impact maps, internal value maps, anything that makes sense based on the context (for example journeys make a lot of sense if the problem has a linear progression and many actors but if there are problems that describe a system then a graph representation might make more sense).

The goal of this phase is to have one clear and well scoped problem statement, which happens to also be the one with the biggest yield. This could be a Job to be done, a user story, an epic, an opportunity canvas, anything that a company uses.

Develop (diverge)

With a clear problem statement at hand, now-ideally- the entire feature team gathers round to generate and iteratively try out as many ideas as cheaply as possible. Design sprints, unstructured prototype interviews, design studios, are just some generative exercises that teams can use in order to try out as many ideas as possible in order to find the most useful (that solves that important problem well) and feasible one (the one that has the highest ratio of value/implementation cost). Typically this phase ends with a User Story Mapping session where the scopes of each release goal are defined in order for the feature teams to start delivering to production.

Deliver (converge)

This is where the rubber hits the road and where most of the world spends their time. You have to get this right, otherwise your solution will suffer but if you have skipped the first three steps, then no matter how well you execute here, you will end up out of business.

Scrum is the framework that everyone uses here and it makes a lot of sense as this is where the entire feature team needs to work together in order to close feedback loops between them and and iteratively ship and improve as early as possible, sprint after sprint. This is, basically, where the “building the product right” tips above, apply.  Usability is sculpted here, at the last responsible moment, not because it’s not important but because it’s the user touch points that you will be working on in this phase. Valuable and feasible should have been tackled before that, otherwise you will run into big problems if you haven’t resolved these by now.

About innovation

Illustration of decrees of divergence from a default path: the earlier you diverge, the higher the possibility to innovate:

  • If you choose to solve a unique and important problem but apply “boring” technological solutions, you will still innovate (think Dollar Shave club with their business model and marketing combination that lead to their acquisition by Unilever)

  • If you choose to solve a common problem but apply innovative technologies, you might still miss the mark (think every bank launching a mobile app to sell you loans, or check the weather)

  • If you solve an important problem and apply innovative technology, you’ve hit the jackpot (think Uber, Netflix, Spotify, Airbnb)

(ToDo: expand and add illustration)

The Chasm

Another big topic for product managers. (ToDo: expand)