How to Build the Right Things, the Right Way

How do top tech companies handle Feature Development?

Different companies (even amongst the largest, and arguably most successful technology companies) have different approaches to optimizing their feature development pipeline. Some invest heavily in a bottom-up approach where employees are encouraged to propose new ideas and experiment with hopes of delivering a product that revolutionizes the space and provides users with a tool they're only now learning they need. Others take the opposite approach, beginning with customer needs and initiating the feature pipeline from the highest levels of leadership; in this model, only when a need is known can it be met. Arguably the two biggest practitioners of these models are Google and Amazon respectively:

Google

• Ideate: Google fosters a culture of creative brainstorming which encourages employees to ideate about solutions to potential user problems. Once a promising idea emerges, the focus shifts to defining the product's core features and target audience, often before the user has any input in the product.
• Prototype: Google's design phase is user-centric. They craft prototypes early and often, allowing for iterative testing and user feedback throughout the development process. This ensures the final product is intuitive and meets user needs.
• Launch: Google's product launches tend to be large unveilings, following months of internal testing by Google employees and external testing by small user groups.

Amazon

• Ideate: Amazon stays ahead of the curve by analyzing customer behavior and market trends before committing to the ideation stage. This data-driven approach allows them to identify unmet customer needs and to develop products that they have reason to believe customers want.
• Prototype: Amazon prioritizes experimentation over lengthy planning stages. They create Minimum Viable Products (MVPs) quickly and test them with a small user base. This allows for rapid iteration and ensures the product resonates with customers before significant investment.
• Launch: Amazon launches aren't grand unveilings – they're data-driven experiments. They closely monitor product performance and user feedback, using these insights to continuously refine and improve the product.

These two approaches may differ greatly in the Ideation and Launch stages, and there is great debate about the merit of both techniques. Where these two great technology companies align is in their ability to iterate efficiently.

Efficiency of iteration is paramount for startups and tech-giants alike. A few of the highest impact decisions companies like this make to iterate quickly include:

• Minimizing the investment in projects that don't fill a user need
• Investing in core prototyping infrastructure and automation to help engineers feel confident and fearless in their pursuit of a product
• Designing with elasticity in mind, allowing engineers, product managers, and users to manipulate parts of the product as part of the experimentation phase

In order to mimic these behaviors, we help companies perform user interviews, build isolated engineering environments, and design configuration interfaces that help them leverage their engineering resources to their fullest.

The User Interview

What is it?

User Interviews - a qualitative research method that involves talking to potential or existing users of your product or service to learn about their needs, wants, and pain points. User interviews can be conducted in person, over the phone, or online.

Utilizing user interviews to inform your feature development is a core component of the feature development pipeline at major tech companies (whether it be at the front of the pipeline à la Amazon, or in the middle à la Google).

Why is it Important?

User interviews allow businesses to see into the lives of their users. Data-driven user feedback can be interspersed throughout the product lifecycle to help designers and engineers align on what will provide customers with the most real, tangible value. Involving many stakeholders at the company in the feature development process will help avoid false positives in the design stage, and will ultimately lead to a more effective product, faster.

When we perform user interviews, we can get additional information that's otherwise not captured bylogging and monitoring. It helps us answer the "why" of user behavior, rather than just the "what". It helps us get a controlled dialogue going with our users to anticipate their needs and mollify their response to any undesirable experiences they may be having with the platform.

When user interviews are used effectively, they can:

• Short-circuit lengthy prototyping that won't ultimately lead to customer value
• Inspire ideation
• Inform prioritization of resources
• Inform design and implementation that best meets the customer's wants and needs
• Pre-empt problems, reducing the load on customer experience staff

Problems at companies without it

Oftentimes, startups find themselves scrambling in the dark to build a product that their users are excited about. They experience high churn, or have increasing demand for customer support staff. They have engineers who are burnt out from chasing the hottest new feature, only to be told that the MVP (minimum viable product) that they build didn't meet the customer's needs, and that the company will be shifting direction.

• Developing features that users don't want or need: Without understanding your users' wants and needs, it is difficult to develop features that they will actually use and enjoy, which can be very costly.
• Building products that are difficult to use: Without user feedback, it is difficult to identify and fix usability problems.
• Losing customers to competitors: Competitors who do user interviews are more likely to develop products and features that meet the needs of their users. This can lead to lost customers for companies that don't use user interviews.
• Draining Engineering Resources: Engineers get burnt out from switching priorities, and not experiencing the validation of an end user getting to benefit from the fruits of their labor.

In an optimally functioning feature pipeline, there would be no false positives in the feature development process. While this goal may be unattainable, it's a useful azimuth and one that top tech companies use to orient their businesses from the top down.

How does this affect the Feature Development Pipeline?

User interviews belong at every stage of the feature development pipeline. They can inform forward-looking and backward-looking objectives and tie otherwise arbitrary feature development roadmaps to user needs. By talking to users directly, we can get closer to WHY they're using our product a certain way. A software company without user interviews is like a ship without a compass.

Isolated Deployment Environments

What is it?

Isolated Deployment Environments - Copies of the product, which are explicitly quarantined off from the customer facing product. These copies allow engineers and product designers to make changes and test without fear of impacting their end users.

When multiple environments are properly configured, teams can feel free to experiment boldly without risk of disrupting customers or internal stakeholders. At minimum, every technology company should strive to have some version of the following three environments:

• Development: The development environment should be used for expedient, real testing of new feature work. It is a playground which can be broken, but efforts should be made to maintain its integrity between testing cycles.
• Staging: The staging environment should closely mimic production in as many ways as is cost and complexity appropriate. Staging should be used to practice rollout procedures, test non-trivial rollbacks, and sometimes to present incoming features to internal stakeholders before release.
• Production: The production environment is the environment which our customers interact with. The goal of any engineering team should be that everyone in the company can safely and confidently deploy features to production. More on how to achieve this to come...

Why is it Important?

Having isolated environments where you can deploy part of your system's architecture are crucial for developers. They allow us to do things that we can't do in production.

• Regression and load testing
• Testing Infrastructural changes
• Testing data model changes
• Provides a safe space for onboarding junior engineers
• Provides internal access to features before they're shown to customers

Problems of companies that lack isolated environments

While the cost of maintaining copies of a system can be high, the value is often extraordinary. Unless you're willing to incur the reputational risk of a deployment gone wrong with your customers, there's no avoiding it.

Companies that don't invest early in building isolated deployment environments:

• Have engineers who are afraid to deploy code
• Release more bugs to customers, delaying the feature development pipeline while teams address regressions
• Have stressful, almost ceremonial release cycles, given nobody (including the engineers who wrote the code) knows how the product is going to perform in production
• Experience slow, sometimes glacial development timelines as engineers constantly search for creative ways to validate before pushing to production

At DRYCodeWorks, we suggest moving your engineering organization model to something like the AWS SRA. We offer clients an Organizational Entity Design Proposal as part of our AWS Infrastructure Audit.

How does this affect the Feature Development Pipeline?

Experimentation is a cornerstone of the creative process. Engineers need to feel empowered to explore without fear of failure. What's more, they need to be able to hurry their new creations into the wild, observe how they perform, and optimize. Their goal when testing a new change should be to break it as many times as they can while they iterate, until it can't be broken. Then it should be presented to internal stakeholders or beta testers before it is enshrined as a commitment that's been made between the company and its users in production. When given an appropriate ladder of release environments, developers will experience minimal friction in pursuit of this goal, and the end feature will be cleaner, more precise, and more in line with the user's needs.

How does this affect the Feature Development Pipeline?

Configuration Management

When dealing with a software product, iteration speed is often a paramount concern. Oftentimes, iteration doesn't require building a new feature, but rather involves modifying an existing one. There are a whole bunch of "configurations" that get applied to a software system, and each of them often have a powerful effect on the user experience. For that reason, large companies often have entire teams dedicated to surfacing these configurations such that engineers, product owners, and operations staff are empowered to make changes to applications instantly.

What is it?

Configuration Management- A cohesive strategy for abstracting / surfacing key elements of an application or system that are likely to change.

Configurations are levers you can pull in your product; they tend to be the part of your product that's most likely to change. Configurations can exist in any and all parts of the software stack, and can take many shapes. For example:

• Processing Power / Memory
• Number of elements to display on a page
• Database queries
• Environment variables
• Identifies for server endpoints
• Credentials
• Colors / fonts / etc.

The list is endless, and abstracting these configurations into a management service is a powerful concept for engineers to follow. Configuration management that happens outside the source code of an application allows teams to move quicker, reduce duplicated work, and reduce the operational dependency on the engineering staff.

Why is it important?

Many common software problems can be solved through abstraction. That's perhaps what makes it one of the most popular topics in software engineering. Abstraction can take many forms, but in some ways, they all center around surfacing more and more configuration closer and closer to the end user. In an ideal world, a customercould pull the levers, and be given precisely the experience they're looking for from a product.

Abstracting configurations can allow teams to:

• Experiment quicker
• Surface different data
• Scale in / Scale out urgently
• Empower non-technical administrators of the platform to make changes on their own
• Loosen the coupling between resources in a system, by creating more flexible interfaces between them
• Improve visibility, reduce risk, and reduce change management friction

Problems of companies that lack Configuration Management Systems

Oftentimes, hardened configuration is a symptom of a larger systemic issue in a company. Perhaps the engineering team could use expert support, or perhaps it's a resource allocation issue. In any case, typically a company that can't configure their product quickly and easily should be talking about configuration management.

Companies that fail to surface their configuration experience:

• Lots of "hard coded" detritus in their application
• Constant need of engineering work to make preferential changes
• Trouble describing their systems
• Repetition of similar engineering work
• Frequent unscheduled deployments at the expense of developer experience
• Major security vulnerabilities due to insufficiently stored secrets
• A lack of experimentation at the cost of creativity, agility, and customer satisfaction

How does this affect the Feature Development Pipeline?

When configuration is sufficiently abstracted, various components of the application come within the locus of control of the stakeholders most interested in them. A flat configuration surface makes it easier to observe the current state of an application, to tinker, to explore. It lifts the burden of parametrization off the engineering team, and relieves the need for future application deployments. All of this leads to efficiency in the prototyping and launch stage of the feature development pipeline.

Final Thoughts

Refining the feature development pipeline can be a terminal pursuit for a company. It's often deeply tied to culture and tends to have a lot of domain specificity. That said, there are universalities that every company, regardless of size or domain, tends toward when building their pipeline. Everyone is looking to build things faster, to innovate, to exceed customer expectations. At DRYCodeWorks, we've developed some repeatable strategies to help most companies meet these goals.

If you're interested in improving your feature development pipeline, and getting more features in front of your users faster, schedule a consultation with us.