The Design & Dev Diaries: Pixel Perfect vs Ship It
When I joined Few&Far back in 2018, I spent six years leading Product Design. Then, around 2023, when the market went suspiciously quiet, I picked up a new skill and started supporting our clients with Engineering recruitment. Unintentionally, I ended up sitting right in the middle of a problem most product teams have wrestled with at some point: do we perfect it, or do we ship it?
For years, I heard the same frustrations from Product Design candidates: “The Engineering team didn’t build the designs how we wanted” or “My best work never makes it out because timelines are unrealistic”.
Then I started working closely with engineers and suddenly I was hearing the other side of the story: “We're debating pixel-level details instead of just shipping” or “The designs aren’t realistic to build in the timeframe”.
Chances are, if you’ve worked in Product, then you’ve experienced this at one point, and you may find yourself nodding along, being able to relate.
That’s why I built this series: to highlight common challenges I’ve heard from both design and engineering, and share insights from leaders navigating them. The first topic is Pixel Perfect vs Ship It. ⚖️
In this edition of The Design & Dev Diaries, I’ve brought together insights from three tech leaders who’ve had to make these calls under pressure, navigating shipping fast without letting quality fall apart:
A big shoutout to the Leaders who contributed to this topic 👏🏼
- Will Porcellini - Engineering Leader, currently Founding Engineer at Jack&Jill
- Renato Cason - Head of Engineering at Visibly
- Filippos Protogeridis - Design Leader at Manual
As a leader, how do you protect quality without slowing things down? 💫
Speed is survival. Only if you're pointed at the right problems!
Speed is often treated as a non-negotiable, especially in early-stage companies where runway is short, ideas are plentiful, and customers won’t wait. But this pressure isn’t limited to startups; even larger organisations feel the strain when delivery slows and quality slips.
The challenge for leaders isn’t choosing speed or quality, it’s deciding where to be deliberate, where to move fast, and how to make those tradeoffs clear to the team.
Here’s how our leaders approach protecting quality while still keeping momentum high.
Will:
Most startups live and die on execution. If you can't execute fast enough, you lose momentum, morale, and ultimately fail. In my experience, the best approach is to set clear goals and ensure your methods align with them. Every feature exists on an ROI spectrum, and the job of an engineering manager is to carefully evaluate tradeoffs and, more importantly, communicate why certain tradeoffs are necessary.
This was a hard-earned lesson. When you become a manager, you think you need to be the best manager people could have wanted, and you focus heavily on pastoral care. In the early stage, the challenge is different. Your goal is to make everyone win. If your startup makes it, this will be great for literally everyone working there. You have a finite number of hours, and your first and second priority is to make everyone win.
Filippos:
Find and treat the root cause. In most cases, low quality comes from not having set a standard for quality, not reinforcing quality in day-to-day work, and design not being close to engineering as the product is being built. Most of these are easily solved by a closer partnership between product design and engineering.
Set the standard. Work with your team to define and document your minimum expected quality. As part of this, make sure to connect quality to better user satisfaction and more impactful business outcomes. (give your team the “why”)
Champion quality continuously. Call out great examples and pinpoint cases where the quality standard wasn’t met. Build strong partnerships. When the engineer is close to the designer during the initial design phases, and the designer stays close to the engineer during implementation, most quality issues are sorted ahead of time with the right compromises being made from both parties.
Renato:
In the startup world, the ability to innovate and iterate quickly isn’t just important, it’s essential for survival. To move fast and maintain quality, the first step is setting up the engineering “machine” properly: automate repetitive tasks, make changes easy to test and deploy, and remove as much friction as possible from the development cycle.
Beyond that, thoughtful planning is key. If a feature is too large or complex to release at once, it’s better to break it down intelligently. Each stage should be self-contained, forward-compatible, and deliver real user value, not just a placeholder or “MVP for the sake of MVP.” That way, every iteration compounds progress rather than creating technical or design debt
How do you create alignment between design and engineering around what “quality” means? 🌍
Quality is not aesthetics - it’s customer value
“Quality” sounds obvious, until you realise everyone defines it differently.
For some, it means pixel-perfect execution.
For others, it means stability, speed, and maintainability.
For users, it often means something else entirely.
Misalignment here is where most design and engineering tension begins. So how do leaders create a shared understanding of what quality actually means and make sure teams are investing effort where it truly matters?
All three leaders were aligned on this point.
Will:
Quality must equal customer value, and this is industry-dependent. Designers might appreciate carefully crafted animations, but busy finance professionals only care about speed. The key is recognising what your customers value, instead of what you value.
I have found that building value usually fits one of two modes, and each has its place:
High-confidence features: When Product has refined something that's the #1 request from all customers, competitors have it, and it's blocking adoption, this is a no-brainer. The ROI is clear. Invest in making it really good because the risk is low and the impact is high.
Experimental features: These require a different approach. Treat them as experiments:
1. Define the question you need to answer
2. Determine how you'll get that answer
3. Build a walking skeleton
4. Send it to trusted customers as early as possible, even as a provocation and define clear exit points upfront.
This distinction is crucial. Not every feature deserves the same quality investment. The art is knowing which is which and communicating that clearly to your team.
Filippos:
Quality, to me, boils down to one thing: does everyone in the team actually care? To define what caring means, you need a set of principles. And there is no better exercise to do for this than getting engineers, product managers and designers in a room, and doing a quick session on defining product quality. The result should be a set of product principles that your teams should always adhere to, no matter what.
The result will be different for every team, but for us it boils down to:
1. Does it solve the customer problem?
2. Does it solve it effectively (is it intuitive, does it add enough value, does it relieve a big pain?)
3. Does it give people joy? (for us in healthcare, joy is a key principle we are aiming towards)
4. Does the build match what was designed? And if not, why?
5. Does it work for all edge cases?
Once you have your definition of what caring means, you need to ensure everyone in your team:
a) Understands if something is of quality
b) Calls out when quality isn’t there
c) Has the ownership and permission to improve quality
Renato:
Quality starts with clarity.
The whole team needs a shared understanding of what we’re trying to achieve for the customer. For me, a quality feature is one that genuinely fulfils the user’s need, is reliable, and feels coherent within the broader product experience. That includes respecting design consistency and platform standards, but also ensuring the solution is maintainable and robust under real-world use.
What happens when you have to prioritise speed? 🏎️
No matter how well a team plans, there will always be moments where deadlines tighten, priorities shift, and speed has to win.
This is where things can unravel quickly, engineers pushing back on feasibility, designers chasing perfection, and frustration building on both sides if expectations aren’t aligned.
The real test of leadership isn’t avoiding these moments; it’s handling them well. That means knowing what to de-scope, what not to compromise on, and how to ship in a way that still delivers real value.
Here’s how these leaders approach speed-first moments without creating long-term damage.
Will:
Speed in Practice. Done is better than perfect. Every feature needs a "won't do" list. My approach: align on MoSCoW prioritisation early, and avoid the trap of demoing north star prototypes to customers only to deliver an MVP that misses their actual pain points. Avoid the feature factory mode at all costs; it's dangerous. You chase immediate customer needs and lose sight of broader product context.
How to win and keep your designers happy
A concrete example: At a previous company, we had three months to rebuild a product from scratch. The accumulated feature set was comprehensive but had a great cognitive overhead for users. Working backwards from our deadline, we:
1. Focused quality where it mattered most
2. Aligned on scope and tradeoffs early
3. Established general principles about where quality was non-negotiable
4. Accepted that less-used features could have rougher edges if the core value was clear
The outcome? We shipped on time with a product that delivered value where customers needed it most, without sacrificing quality where it truly mattered. I can't fully disclose the outcome due to NDA, but rough metrics showed user satisfaction in the high 90s.
Filippos:
Find the balance. You can’t always prioritise speed, and you can’t always prioritise quality. Building the critical thinking to know when to opt for one or the other is crucial for every discipline within the product function.
Choosing a safe, speedy solution (existing patterns and components, small changes) is sometimes necessary, particularly for a well-defined, small problem. On the flip side, opting for something that’s higher-effort is often the only way to solve a problem effectively. A practical tip that I advise all of our teams is to do a quick check-in at the beginning of an initiative; is this something we want to ship quickly (and if so, why)? Or is this something where we can go a bit wider and deeper in order to push the status quo?
Always remember to prioritise speed of learning. If a small-scale, speedy experiment will lead to great learning (rather than insignificant incrementality), we’ll prioritise shipping it as quickly as possible while maintaining quality standards. A series of small experiments that lead to great insight will often be followed by a much bigger bet that uses our combined learnings to completely change an experience.
Renato:
That happens regularly. Usually, it’s not an issue because we plan in a way that allows us to release incrementally, delivering value in adjacent sprints. The challenge comes when priorities shift mid-way and a feature remains incomplete for longer than intended. It can cause short-term pain, as users interact with something that’s not yet fully released, but in many cases, it’s still the better choice than not releasing anything at all.
The key is to maintain discipline: shift priorities as little as possible and make sure partial releases are still meaningful and stable.
After spending years working closely with both Design and Engineering teams, I’ve realised that the “pixel perfect vs ship it” debate usually comes down to one thing: alignment from the start. When teams take the time early on to align on what quality actually means for a product, and what the real priorities are for the user and the business, it becomes much easier to move quickly without compromising on the things that really matter.
What also makes a huge difference is communication and curiosity between teams. The best product teams I’ve seen don’t operate in strict silos where designers only think about craft and engineers only think about delivery. Designers start to understand the realities of how things are built, and engineers understand the thinking behind design decisions. Regular check-ins, open conversations, and a willingness to learn from each other go a long way in preventing friction later on. When that foundation is in place, speed and quality stop competing with each other and start working hand in hand.
