You know what you want to do. You've done the buy vs build analysis and you've determined that it's worth building custom software. You defined the features, the product you need to deliver. You’re looking for a vendor to contract for those deliverables. Why, then, is Lab Zero sending you a proposal that includes people and roles you didn’t ask for?
Lab Zero was hired to help improve the speed and cohesiveness of a major online retail company’s React-based web storefront. Our main goal was to reduce the size of the JavaScript and CSS bundle downloaded by each visitor. This level of optimization might seem excessive, but this client reached a level of scale with their business where even small performance gains can have a surprisingly large impact: the duration of these downloads was shown to cause fluctuations along the lines of hundreds of millions of dollars of revenue annually; users, especially those on slower connections, would leave the site before it finished loading.
Building and maintaining custom software can be a pretty big investment of time and money. Custom solutions aren’t just for big, established companies. Many startup business models depend on custom software development using platforms like Ruby on Rails. We’ve had lots of conversations with decision-makers in a variety of situations, and we know where you’re coming from. Making the decision to build a software solution comes with excitement and some anxiety. The fear of failure: fear of wasting your time and money on something that doesn’t make a difference--or that makes a difference in the wrong direction. The excitement of creating something uniquely valuable that differentiates your company or product year after year. It’s the kind of decision that can keep you awake at night, no matter what you choose to do.
A Fortune 5 technology company asked Lab Zero to explore Tableau; a business intelligence tool for connecting to myriad data sources and creating advanced data visualizations. We built a reporting infrastructure for an organization with disparate data sources, and gained some insights on Tableau along the way.
The team looks to the Product Manager to establish the product vision, to set priorities, and to act as primary liaison to stakeholders. Setting priorities- and communicating the priorities effectively- aligns the team for value creation while eliminating waste. But managing priorities and expectations is a challenging task, and as a web development and design firm we've seen lots of different ways to do it. Here are a few tools in our prioritization toolkit that we’ve used in challenging situations.
It's received wisdom that the developer just needs to understand how the design works, and implement it without changing it. But how many times does the developer start coding the design, and notice something that wasn't anticipated by the design? We find that it's quite often. Our developers specialize in Ruby, Elixir, Angular, React and other frameworks. The developer is the first person who actually sees the system doing (or trying to do) what the user needs it to do. What kinds of observations do we harvest while they’re in the throes of writing the code?
We at Lab Zero are big Mad Men fans. We’re also fans of building valuable products solving users' problems.
Your demo is going super-smooth. No cracks. No gaps. Everything is working according to design. A dynamite end to a flawless sprint. Then Dave, who has been absent most of the last quarter, stands up and says:
In many ways, Covid has just accelerated the evolution of software development that was already in progress. Virtual collaboration, empowered teams, new models for meeting across time and space: we are all turning a corner toward a remote-first workplace. Some developers who had already made the jump to remote work are thriving, and even designers working remotely for the first time have prospered as well. Fewer meetings, more accountability, and management by results are music to the ears of many. But overall, Covid hasn’t meant a rosier world for producing high quality software. There’s a difference between having options for how to work and having a single option imposed overnight. Here are a few of the hurdles we’re seeing our clients encounter, and how we’re helping them overcome them.
We may think the toughest challenges in an Agile project are domain-specific — how to use our distinct engineering, design and product skills to create something that’s desirable, viable and feasible. We focus on improving our process, frameworks and tools.