If R&D, then CC – how the backend of customer-centricity works

How a perfect unison between frontend and backend makes customer-centricity happen

The audience sees hero Elon Musk disrupting the NASA space hegemony. Straightforward communication and sleek design serve a simple purpose: making the space and beyond dream tangible for everyone.

What fascinates me is the innovation process behind that. Because that’s the grounded reality that’s putting people into space. It clearly illustrates how a perfect unison between frontend and backend makes customer-centricity happen.

Customer centricity is about keeping a continuous focus on what the customer wants and needs to secure the best possible customer connection. Customer success plays an essential role in captivating, processing, and validating all customer feedback, **but only a few are aware of the R&D backend that drives the frontend. **

That’s why the SpaceX dragon mission triggered me; it is software development at its very core. The trial/error/failure/success matrix births the design, develops the solution, and realizes the dream.

Because if customer-centricity is a feeling on their end, it's strategic math on our end. And here’s how.

Why we calculate opportunities, not risks

Every feature we develop serves a purpose: we’re optimizing our solution to make users happy. That means that every development we put out there must enhance the solution AND benefit the customer.

Does this come with risks? Absolutely.

But in my experience, we get better results when we see these as opportunities. Some you take, some you don’t. But we assess every one of them positively.

You know the ‘Fix one bug, unleash five others’ saying? We think it works better with opportunities.

How do we calculate the feature-driven development opportunity?

1. Coordination with customer success comes first

Developers don’t have a customer-facing function. That’s important to keep us as neutral and objective as possible when preparing the solution roadmap. All customer feedback reaches us via our customer success team. We collate all feedback, assess and rank each request, and schedule it in the short/long-term planning.

We report back to the customer success team, who will discuss it with the customer. But we need to work independently from ad hoc urgencies, so we can factor in long-term necessities.

2. Opportunity score mapping determines the timing

Each item on our agenda gets scored. **We measure recurrence against impact, profitability against philosophy. Is the work worth the effort, and will the effort be worth the result? **

• If yes, great.
• If no, drop it.
• If maybe, back to the drawing table and re-assess.

Is this exact science? No.

But marginal accuracy goes a long way when preparing our planning.

3. Company & customer commitment hierarchy rule

We're software developers, everything is a trade-off. How will each feature affect our code for current and future features? And which comes first?

• The customer comes first – we solve tickets, issues, bugs when and where we need to.
• The company next – what does our solution do now, what could it do in the future, how will that serve our customers better? These are more strategic, long-term decisions, but they continuously run in the back of our heads.
• The mix of both is the ideal combination. We communicate on the added value of an upgrade/technical replacement for both parties and work in a realistic timeline.

What’s our calculated opportunity? Middle ground.

We determine how much time will be spent on fixes, developments, disruption, and innovation. And we stick to it.

How we perform a reality check on the visionary roadmap

As far as management and customers are concerned, every release is too late. The go2market strategy waits for no developer. And yet, it’s up to us to deliver a realistic roadmap to turn strategic decisions into practical product developments. Here’s how we go about:

1. Check dev feasibility – how long will it take for how many people to develop?

For every item, we keep following in mind:

• Think opportunities, not risks. Suggestions are never a write-off, but some items may need to make way for more pressing matters.
• If it’s not broken, don’t fix it. Unless you can improve it. That’s how Dynamic Layouts came to be.

"We had an "anchoring" feature that was fully operational, but also slow and not flexible. Extensive use of the feature degraded performance. Dynamic Layouts proved way more functional, so we replaced the anchoring engine with the new Dynamic Layouts engine. Two birds, one stone: a new extended functionality, and improved existing functionality.”

2. Balance – how will each development impact each customer positively/negatively?

Every code alteration comes with software impact, that calls for some careful consideration. Which is why we:

• Vote. Determining which major elements get processed first is a company effort. We outline what can be done, what will be the effect, and what will be the impact. This doesn’t apply to minor bug fixing. (We eat those for breakfast.)
• Set the pace. When do we sprint, run, walk, or pause?

“With web2print booming during Corona, we knew a lot of printers would benefit from a SaaS CHILI publisher. We sprinted to hit the ground running. CHILI publisher Online happened in just four months.”

3. Focus - It’s a chicken-egg situation sometimes, but a 100% customer focus & dedication mindset help us not to lose track of our priorities.

This is why we keep following line-up in front of us:

• customer commitments
• strategic developments
• crystal ball decisions

Why R&D assumes accountability for solution ownership

You may have guessed by now; it takes significant efforts to make the backend run smoothly enough to make it easy for the frontend. Software development is calculated opportunity creation. And because we’re frontrunners, we tend to make it difficult for ourselves.

So how do we reinvent ourselves, even when we sometimes feel like we’re stuck in the mud?

1. Get yourself a fantastic team.

Our people are not just writing code; they are developing your next applications. I find them always thinking three steps ahead, keeping last year’s faux pas in mind. That’s the kind of holistic software approach that will build the future of graphics.

“Agile & scrum is how we assess long-term, short-term, and ASAP actions. It’s a quick & efficient communication effort that helps us redirect resources, assign responsibilities, and brainstorm possibilities.”

2. Never not moving forward, onward, and upward.

We're always aware of our roadmap tracking. What we did yesterday, impacts what we do today, influences tomorrow, and paves the way for the future. That’s why we deal with regression issues asap and always focus on peak performance.

Why? Because we’re software engineers – backend or frontend, we deliver in any end.