Vision to Value Archives | Vision to Value

Category: Vision to Value

Working from Value with Outcome Roadmaps

July 17, 2020July 17, 2020
by Luis Gomes de Abreu

Developing a Backlog based on Outcomes Not Features

Delivering value to the customer, typically through solving problems, is the end goal of any organization. This is true of any organization. Facebook delivers a social media platform, but they solve problems like enabling communication and delivering an outlet for people to broadcast what and how they feel.

But, if our businesses are based on solving problems, why do most roadmaps focus on features? Take a look at nearly any backlog and you’ll see a list of feature requests. Ask internal teams for backlog suggestions, and they’ll typically suggest widgets, website speed, or specific features. Everyone is focused on building something rather than solving problems. Developers fill orders to deliver specific requests, and that’s it. The result might be that your team is working hard, delivering feature after feature, and the product doesn’t improve.

Outcome roadmaps, sometimes called value roadmaps, are one solution that can help you get more from the backlog, with better prioritization and more focus on the end-customer.

Defining Value

What is value in your organization? What is value for each of your customer segments? What problems are they facing? Feature roadmaps don’t work because they focus on adding more to what you have, rather than improving, optimizing, and creating value. Building an outcome roadmap necessitates stopping, analyzing customers and their needs, and analyzing the product. This should involve in-depth conversations with sales, marketing, and customer service, because these teams will have good ideas relating to what customers complain about, what they want, and what they need to solve.

What problem(s) does the product solve? How could you improve that?
What would improve the customer experience with the product
What complexities do customers find when solving their problems? Can you solve those complexities?

Once you answer these questions, you should align them with specific and measurable “outcomes”. What does that look like?

Problem: “Landing page conversion drops off at 3%. This is likely because the signup widget takes too long to load”

Problem: “Customers waste too much time manually downloading data and filling out reports”

Both of these problems could be shared to a development team, which could find solutions to the problem, validate them, and design the best solutions for problem based on the software, other problems, and needs.

Aligning Outcomes and Solutions with Strategy

Any solution must align with the overall business strategy. Any solution or idea must be validated against real customer data, against business strategy, and with the end-user. If you hand developers a problem, they can get to it in any way that most suits the situation and the tools at hand, but that solution and the result must be validated.

What do we need to do to achieve the vision?
Does this solution work for the end-user?
Does this solution fit the budget?
Does this solution move the organization closer to goals?
What are some challenges of taking this approach? Is another approach easier?

If you’re organization traditionally works with a top-down approach, teams might need training and practice runs to perfect this. Feature validation is easiest when dev teams have access to Q&A and to customer service.

Creating a Feedback Loop

Outcome roadmaps can create immense value for organizations in that they can be used to develop recurring feedback loops. Dev teams are handed a problem, they devise a solution, receive more feedback, offer more solutions. Outcome roadmaps are, eventually, about bringing the customer and the customer’s needs into the development cycle, implementing direct feedback from customers, customer service, and quality assurance.

A good feedback loop integrates the customer and regular checkpoints, validates problems and solutions before beginning work, and makes creating solutions a collaborative process, with every team aware of what every other team is working on.

Vision to Value is an operational framework designed to help tech organizations step away from top-down management and towards Agile structure, promoting consistent, quality, and predictable delivery. Creating good operations and processes is key to implementing the switch to outcome roadmaps, focusing on delivering value rather than features.

Product Development Team Structure for SaaS Organizations

April 14, 2020April 14, 2020
by Luis Gomes de Abreu

Product development teams are the most crucial point in any SaaS pipeline. Despite that, many SaaS startups have little if anything in the way of team organization. When you first launch, chances are, roles and teams are poorly defined, if at all. Everyone takes on multiple roles and does what’s needed to get things done. As your organization begins to scale, new employees onboard, volume increases, and structure becomes critical to maintaining output.

Structuring product development teams typically requires adopting a framework, deciding on a priority structure, and valuing work across your organization. This article includes basic information for structuring product dev teams and offers some tips and advice from the book, Vision to Value.

Team Frameworks for Product Development

Product development teams should almost always work using an Agile framework. Why? Waterfall frameworks, using massive upfront planning, leave no room for mistakes or major obstacles. If you determine something can’t be built 5 months into the process, everything must be scrapped and you have to start over. Agile allows you to develop in small, flexible steps, make changes based on obstacles as you go, and essentially work backwards from creating value to how your product must start.

Of course, Agile comes in many “flavors” and you’re free to choose the model you want. At Nmbrs, we use a variation of the Spotify Model.

Spotify Model – The Spotify model is based on the Agile framework, with the addition of a cross-functional structure integrating teams together based on functionality, expertise, and role. So, while teams are composed of people from different disciplines, those people are connected to other persons with the same business area, area (such as “Front-end), and common interests (such as “Quality Assurance”). These cross-functional groups allow Spotify to create small, highly autonomous squads that remain connected to others across the organization. It’s a great way to implement Agile and cross-functionality, without creating silos or isolating experts.

Some other, very popular, agile-based frameworks include Scrum, Crystal, Dynamic Systems Development, and Feature-Driven Development.

Your best option is to research your options and choose a model that best-suits your organization. Of these, Scrum is the most popular. You could also develop your own, but with hundreds of quality team frameworks and models on the market, it’s faster and more efficient to adopt something and adapt it to your needs.

Building Cross-Functional Teams

In most cases, product development teams should be cross-functional because it enables you to better utilize skills from across departments, rather than forcing teams to transfer work between teams. Why is this a good thing? Giving teams full ownership of a module or feature allows them to work on that feature at their own pace, with no bottlenecks, and no delays except where features or models interact with other parts of the application. It’s faster, more efficient, and allows your team to be as innovative as necessary to solve presented problems.

Start with Responsibilities – Teams are normally designed around a “purpose” or “goal” such as “delivering a mobile experience”. This can result in difficulty as that goal or purpose is completed or changed. For this reason, you should consider designing teams around responsibilities. In this case, “maintaining application code” and then assigning that team to the module. If the module changes or becomes obsolete, the team purpose doesn’t have to change to assign the team to something else. At the same time, it’s important to assign teams to individual features and models because this ensures everything is stable and attended to.

Choosing Roles – Team roles should be chosen based on the team purpose, so that individual skill sets are aligned with those goals. While there is no one-size-fits all structure for product development teams, the following roles add value to development.

Product Owner – The product owner is responsible for backlog and its prioritization, aligned with stakeholder expectations. This person may also be a QA.
Scrum Master – The role of any scrum master is to remove impediments. A good scrum master also focuses on teaching teams to identify impediments autonomously, eventually making themselves obsolete. Most product development teams should have access to a scrum master, even an external one, for support, operations maintenance, and day-to-day work that would detract from team productivity.
Developer – Most teams need at least 2-4.
Quality Assurance – Integrating QA into development means better quality assurance, more in-depth testing, and quality assurance that begins when development does. If the QA is part of the team, they understand the use case, how it works, and can begin validation to ensure the user perspective is brought in from the start. Here, the QA takes on the role of quality engineer, everyone tests quality, QA processes are automated so that code can continuously be tested.
Customer Support – Support consultants are a direct line to the customer and will bring the user’s voice and perspective to development. Integrations can take two forms, either directly implementing someone from third line into a maintenance team, or including support consultants in kickoffs, planning, quality assurance, and in weekly meetings to “touch base”.

Size – Small teams are agile, flexible, and can quickly make decisions. Larger teams are more stable and reliable (They won’t drop work productivity if someone is sick or takes parental leave) but slower and less agile. Product development needs both. In most cases, small teams should include 3-5 people and large teams should comprise 6-10 people. Amazon’s famous “two pizza rule” stipulates 3-10 people in a team. Other organizations use their own rules. Basecamp limits teams to just 2-3 people.

What should one of these teams look like?

TeamC, a small innovation team, is composed of 3 developers, and a product owner who is also a quality engineer. The team receives external support from a scrum master serving other teams with the same business function. Weekly meetings are held with a support consultant to track updates to customer needs and user perspective.
TeamZ is a maintenance team responsible for a major feature. TeamZ comprises a product owner, scrum master, 4 developers, quality assurance, and a third-line customer support agent, whose primary responsibility lies in customer support. This allows TeamZ to fully own maintenance of their module, directly receive tickets from customer problems, and connect to how customers are experiencing the module.

There is no one best way to design a product development team. However, most organizations greatly benefit from cross-functional teams capable of owning features and modules, and capable of working on and achieving goals with minimal management and minimal dependencies on other teams.

Building a team structure for your product development will likely involve trial and error, and likely, several different types of teams. The team must fit the module or feature, and that often means building teams in different sizes, with different goals, and completely different work methods. Vision to Value offers a high-level Agile framework, with everything you need to structure teams, implement scalable processes across teams and pipelines, and scale operations in SaaS organizations.

How to Maintain Business-as-Usual When Working from Home

April 2, 2020April 2, 2020
by Luis Gomes de Abreu

Modern innovations including cloud, virtual desktops, file sharing, video calling, and instant chat mean that employees have more opportunities than ever to work whenever and wherever they want, including from home. For organizations, that has historically meant keeping tight reigns on individuals in the office, but flex work and work from home are increasingly not just considerations but the norm. Today’s advent of real-time communication, cloud-based workflows and applications, and digital services means that many organizations can seamlessly switch to a work from home or flex-work model, with employees following the same processes, on the same machines, from home rather than from an office. Today’s rapidly changing environments often forces organizations out of comfort zones, as employees and conditions increasingly demand remote work. This escalated following measures to slow the spread of Covid19, with most organizations forced to rapidly adopt virtual work environments.

While doing so is relatively simple for organizations with established cloud tools, virtual desktops, VPNs, and processes to support working from home, most organizations have little experience in supporting working from home, maintaining processes, tracking work output, and otherwise continuing business as usual.

Making (Virtual) Processes Available

While you can’t switch your organization to virtual desktops and full cloud based environments within a few weeks, you can ensure that processes, networks, and tooling are available to everyone. Virtual Private Networks can be set up in a matter of a few hours, leveraging existing servers and networks. And, your processes should be made available through either existing tooling or new solutions. Exporting processes to tools like Jira, Asana, SAP Cloud Platforms, and many other tools allow you to export processes and documentation to a cloud tool. If you don’t already have cloud available, teams can upload their own processes relatively quickly, enabling fast and efficient access to those processes from home.

Why export processes to the cloud? Even if you only maintain work from home capability for a few weeks, doing so will help you to identify bottlenecks, keep people on-target, and identify process impediments. It’s easier to recognize issues with working from home if you’re moving processes into the cloud, because you’ll see everything upfront. These might include inaccessible tooling or workstations, time management issues, team environment restrictions, product owner availability, stakeholder availability, etc. Recognizing them upfront allows you to plan for those impediments, create measures to move around them, and move forward.

It’s also critical to maintain business structure and processes, even during an emergency, so that you can maintain schedules, remain compliant, and hold to client or stakeholder agreements.

Communication and Connection

Magic happens when you bring people together. But, what happens when you don’t? Technology allows us to communicate more quickly, efficiently, and more cheaply than ever before, but video calling will never truly replace face-to-face conversations. What’s important, and how do you best mitigate the decreases in productivity and creativity caused by splitting people up?

Daily Standups – Daily standups or video conferences are important for many teams, but they should be essential for any team working remotely. Consider starting every day off with a standup, where teams check-in, discuss progress, set goals and priorities for the day, and go over each other’s work.

Consistent Communication – Teams should have easy ways to communicate throughout the day. Tools like Slack are ideal, offering chat, calling, file sharing, and local team environments in one place. Other tools, like Discord, Zoom, Microsoft Teams, or Workplace by Facebook offer simple ways to connect in different ways, with a variety of features useful for different types of teams. Smart tools like ConceptBoard mean people can collaborate on digital whiteboards in real time. And, digital offices ranging from Microsoft 365 (formerly Office) to Google Drive and Adobe Creative Cloud allow real-time virtual collaboration on files ranging from photos to documents to code. Implementing these channels means that teams can maintain running dialogue throughout the day, just like they would when working together in an office.

Quality Tools – It’s important not to ask everyone to join in on a video call if most people will be calling without headsets or with poor-quality tooling. While a laptop with a decent camera (or a phone/tablet) is more than enough to create a quality calling experience, it’s important to review connection, capability, and your ability to eliminate background noise or to ensure everyone is heard during a call. Why? A frustrating calling experience usually means everyone is focused on the frustration and not on connecting and collaborating.

Maintaining Normalcy

People often switch to working from home and lapse out of normal schedules. They can wake up later because they don’t have a commute, work later, because they have nowhere else to be, and otherwise fall out of normal routine. Doing so can be a mistake and can be detrimental to productivity.

Instead, try maintaining existing routines. Start the day at the same time, with a video conference or stand-up. Maintain regular meeting schedules. Stay on track with scheduling. And, establish guidelines as to how and when managers and other employees can contact each other about work. Establishing guidelines relating to personal privacy is just as critical as establishing guidelines for work output and productivity, because the two affect the other. Someone might over-work for the first few days and then fall into a slump. Or, they might lose motivation because they’re constantly being asked to work.

Changing how people work will always impact productivity at first. Team effectiveness will almost always decrease when people start working from home. In the end, working from home is all about building new and sustainable habits, relying on your existing structure. Once you establish that, your organization can likely easily switch back and forth between home and office work with little to no impact on output.

Starting a Tech Company for Non-Tech Co-Founders

October 26, 2019December 27, 2019
by Luis Gomes de Abreu

In 2011, Marc Andreessen wrote “Software is Eating the World” a think piece detailing how companies are increasingly software driven. Today, that statement is more true than ever before. Millions of businesses launch every year and they are more likely to be tech companies than at any other time in history.

While a “tech” company might use software to drive physical production and services, sell software as a service, or fit software solutions into any of a variety of other “flavors”, they are tech driven. This is true for giants ranging from Amazon to Google to Facebook. But, while tech companies are now becoming the norm, many founders and co-founders have no real idea that they are in or are building a tech company. While that might be intimidating or might push many entrepreneurs into waiting to launch their business, it’s also increasingly a norm.

Most Tech Companies Aren’t Started by Tech People

Jeff Bezos, CEO of Amazon.com graduated with degrees in engineering and computer science. Jack Ma, founder of Alibaba, graduated with a degree in English. Airbnb was founded by two designers. The founder of Group and the founder of Pandora both have backgrounds in music. And, the founder of NerdWallet started the $500 million company after being laid off as a financial analyst. Millions of co-founders start tech companies, with no real idea of what a tech company is. But, that’s also the norm for many organizations, who are driven by people who excel at creating solutions, not at running or designing companies. In fact, 33% of S&P 500 CEOs graduate in engineering and 11% in business administration.

Running a Tech Company Requires a Shift in Mindset

Most non-tech co-founders launch a company and approach it from the perspective of a product. Your organization works to develop a minimum viable product and then bring it to market and focus on making sales. Tech companies don’t work this way. Instead, you have to treat development as an ongoing process. All business structure and operations have to be driven by long-term develop and continuous improvement.

It also changes how organizations operate, with operations, finance, customer service, sales, and HR very heavily tied into the same processes and value streams.

Making it Work

Your role in your organization will heavily depend on how many co-founders you have and what their roles are. If you’re going at it alone, it makes a lot of sense to partner with a technical person who can help bring your vision to life. If you already have a technical co-founder or don’t want one, your priorities should be building operational structure, hiring on technical people, and creating the foundations that will allow developers to build your product around that vision. In the early stages of a startup, your role has to be about getting people on board, pitching your product and vision, and creating a brand that sells your product. This will eventually include networking, pitching your product to funding, and possibly taking on a role like COO or CEO. While this will heavily depend on your organization, your role as a non-tech co-founder will be to ensure you understand how tech companies work, to support the structure enabling continuous growth, and to help the organization grow through bringing on skilled people, marketing, and earning funds.

Vision to Value is a deep dive into high-level operational structure for tech companies. With information on how to structure tech companies for continuous development and value delivery, Vision to Value is designed to help you build the foundations of a tech company.

Learn more about Vision to Value

Team Predictability in Agile Environments

October 11, 2019December 19, 2019
by Luis Gomes de Abreu

Agile is increasingly seen as a must-have for tech companies. With advantages including flexibility, faster delivery, and more room for creativity and innovation, Agile allows organizations to develop new products and features without massive upfront investments or risk. But, while Agile is immensely valuable for development, developing in short iterations with no planned work and only a backlog of desired features makes team predictability difficult.

Unfortunately, these predictions are often necessary for stakeholders, investors, and even customers who might need to know where you’re headed and why. While you’ll never be able to make Agile teams as predictable as Waterfall teams, you shouldn’t have to. Instead, you should be able to design operations around team predictability.

Working from a Backlog

Agile teams should always work from a backlog of desired features or changes. Doing so in a predictable fashion means establishing those backlogs, assigning technical debt, and actively working to link those items to business objectives. This may require tying in both long-term business objectives from the business plan and short-term feedback and goals from customers through customer-service and sales.

Developers need to know what they are working on and why, and you must be able to track that work to business objectives. This also means establishing standardized measures or KPIs to track how and what developers are creating.

Establishing Predictability Metrics

Team predictability depends a lot on what you want to measure. Depending on your organization and its goals, you might want to predict turnaround time, quality of work, or rate of innovation. In most cases, the actual value of each of these statistics will heavily depend on your organization and its structure.

For example:

Cycle Time – Cycle time can show predictability but this will heavily depend on the size, difficulty, and quality of work items.

Sprint Value – Measuring value produced per sprint might allow you to predict average turnaround, but again, this heavily depends on organization, structure, and how work is organized and distributed.

Quality – Measuring the quality of work (hopefully from a customer perspective) will give you an idea of what teams are doing.

Maintenance vs Innovation – Measuring whether teams are performing routine maintenance or creating new things and new value for customers is important for predicting what and how teams are delivering.

Clear Communication During Kickoff

It might be surprising to hear that many team delays aren’t related to bad code or poor solutions. Rather, they’re related to teams having a poor understanding of what they were solving when they started. Any team needs a clear understanding of what they are building and why before they begin. Once you’ve established a clear backlog, sharing that information with your teams is crucial.

Stakeholders must have channels in place to communicate what they want or need to developers. Using standardized communication channels and investing in longer and more intensive kickoff sessions with stakeholders are two strategies to ensure teams understand what they are working on.

Sharing Estimations with Stakeholders

Agile teams are not designed to share precise deadlines and output expectations. Instead, you should always communicate in terms of backlog and team objectives. Stakeholders can make decisions based on backlog, while understanding that work and therefore output can and will change based on technology, what happens while the team is working, and the market.

Improving Team Predictability with Operational Framework

Vision to Value shares an operational framework designed to help tech organizations structure the organization, teams, and development to create consistent, quality, and predictable delivery. Structuring teams around desired output, creating measures for continuous delivery, and implementing measures such as quality gating and automation are all crucial to long-term predictability in Agile development environments.

Get the book now to learn more.

What is the Tech COO Role?

October 4, 2019December 27, 2019
by Luis Gomes de Abreu

The Chief Operating Officer or COO role is one as much defined by ambiguity as a list of tasks and role responsibilities. As a result, many tech startups wait to implement the role or simply avoid having it, often until far too-late in the game. And, ambiguity is understandable. While it’s easy to define what a chief marketing officer is responsible for or a chief technology officer, defining “Operations” is nowhere near so simple. The Tech COO and her role are defined by the organization, their relationship with the CEO, and the size of the organization.

This is especially crucial in tech organizations, where the role of a COO likely merges business operations (strategy, business growth, etc.) with tech operations.

A Partner for the CEO

The CEO is in charge of creating and directing vision and strategy. The COO should be her partner, directly working to act on and realize that vision and strategy. If the CEO is “what” the COO is “how”.

In many ways, this means that the ideal COO for your organization is one whose skills and personality complement that of the CEO. So, if the CEO has ideas but no practical way to scale them, the COO would step in to scale. Or, if the CEO has experience with operations, the COO might operate as a business partner, sharing work and ideas in an early startup.

What does the COO do in Tech Organizations?

The COO role is responsible for creating operations and structure supporting the day-to-day delivery of your organization’s products and services. That typically means architecture, business processes, product development, support, team structure, etc. Tech organizations, operations enable the sustainable creation and development of a software product, meaning that operations is about structure, people management, customer support, product development, product management, and support. Here, it’s crucial that organizations see the entire organization as a product, which the COO must oversee.

A tech COO is a strategist, an executor, and, to an extent, a jack of all trades. He should expect to take charge of operations and delivery, to work in interconnected roles with finance, sales, account management, marketing, PR, HR, and IT, and to realize the CEOs vision and strategy. In startups, the COO will often fill numerous roles, especially that of CTO, but this will heavily depend on the organization.

Operations is an important tool for any startup. It provides the structure to deliver software in a timely manner and to a consistent standard of quality, even as you scale. It enables organizations to grow and develop new ideas and services.

The Vision to Value Framework describes operations from a technical perspective, helping COOs design operations around the needs of their organization and its software product. With a high-level view of operations in tech companies, Vision to Value works to help COOs create and maintain a structure to support scaling tech organizations.

Get the book now.

Why Tech Operations is Key for Startup Success

September 19, 2019December 26, 2019
by Luis Gomes de Abreu

Starting a new business is a step that takes time, planning, and preparation. With over 3 businesses launched every second, any new organization will face challenges, competition, and rapidly shifting markets. A large percentage of those new businesses are tech companies, and, unfortunately, most go on to fail. Navigating the complex waters of launching and scaling an organization requires having the right elements in place at the right time.

While there are dozens of factors contributing to long-term success, including timing and understanding your market, technical operations is one of the most crucial.

What are Tech Operations?

The value chain includes everything that is completed in order to produce value. Operations includes the structure, planning, and strategy behind that value chain, making up the strategy behind work completed. In tech organizations, this includes designing teams, processes, work methods, departments, communication channels, sales, marketing, and much more.

Business operations defines how and why people work, connecting work to goals, and creating defined channels, goals, and output for work. Operations can be responsible for such diverse initiatives as business intelligence, system administration (CRM, product development tooling), creating feedback loops between customer service and product development, and so on.

Why do Startups Need Operations?

Very-early startups don’t benefit a great deal from defining operations and structure. Instead, everything is typically performed by whoever can do it, whenever they can do it. Structured tech operations become crucial as you start to scale. Here, operations function as a sort of roadmap and structure, offering guidance and support as your organization grows.

Why is this necessary? Kickstarter projects are extremely common, but many go on to fail and never actually deliver. While reasons are diverse, most simply don’t have the resources or planning in place to handle meeting quality and volume demand continuously. Orders increase, server load increases, demand for new features increase, and demand on customer support increases – at the same time. If you don’t have structure, you simply won’t be able to meet these needs in an organized way and affordable way.

Operations is a structure that ensures you can, by defining how and why you will meet demand, putting processes into place to scale up without losing quality, and integrating tooling to ensure quality and output. Whether these include processes around hiring and onboarding new people, integrating business processes into tooling, or using automation is less important than having the structure there to begin with.

Getting Started with Tech Operations

Scaling a startup is very much about structuring tech operations and building sustainable foundations for the future. The Vision to Value Framework covers operations from a technical perspective, helping organizations design operations around the needs of design, development, and a virtual product. While operations should also include extensive team-design around individual products and output, Vision to Value offers high-level input for top-down operational design. This will be crucial as your organization begins to scale, because it ensures you know how, where, and in what direction your organization is working towards. Structuring operations for tech companies means shifting perspective to long-term development and delivery, with infrastructure to support continuous quality output. Vision to Value walks you through the important aspects of tech operations to help you make those decisions for your organization to better realize long-term value.

Request your beta copy to read Vision to Value now.

What is Operations in Tech Companies?

September 11, 2019December 26, 2019
by Luis Gomes de Abreu

Today’s businesses are increasingly tech-oriented, selling not manufactured goods and products, but rather services and downloadable products through online platforms and apps. This shift in how goods are distributed is a natural one, as consumers increasingly seek out digital services, solutions, and information. It also necessitates a fundamental shift in how organizations approach tech operations.

At its most basic level, operations are defined as the framework designed to keep the company running and earning money. However, this framework and its pieces look significantly different in tech companies than in something more traditional, like a manufacturing plant. Understanding those differences can help you to build better tech operations, capable of supporting scaling organizations.

What’s Included in Tech Operations?

Tech operations are quite simply the framework (typically communication) behind running an organization. For most organizations, this includes support functions, value chain, and strategy. The specifics might vary from company to company but should likely be outlined in your business plan.

Systems – Systems include processes, communication channels, networks, and other means of connection. These can be as simple as establishing work processes, creating portals, creating knowledge bases, and so on but can be as complex as aligning overlapping departments, coordinating finance, HR, and customer service, documenting work, or managing external relationships.

People – People are the core of any tech company. The more software-oriented your company, the more people become your most valuable resource. People must be organized, given structure to work well, hired to meet strategy and goals, and trained to continue to meet the goals of the organization. Operations tackles questions like “who should be hired”, “how should people work”, “where should people work”, and even “what is work”.

Technology – Operations covers hardware and software tooling, helping to choose the items that facilitate work. This might include software tooling, it might include automation, and it might include items such as integrating work processes into tools and software.

Tech operations very much focuses on people and helping people to perform work. This isn’t always the case in other types of organizations. For example, manufacturing tends to focus more on product, product development, and transit.

Operations exist to enable businesses to function in a way that drives value for the customer and for the business. This means that operations are functions designed to allow businesses to perform work as usual, to optimize that work, to increase the value delivered to consumers, and to excel. Formal operations offer limited value in the very early stages of an organization, but become increasingly valuable and necessary as your organization grows. Establishing operates at an early stage means you’ll have the foundations to scale effectively and sustainably, because you have the framework in place to do so.

The Vision to Value Framework is one solution to implementing structure at this stage, because it approaches operations from the perspective of development and enabling people and technology. Paying attention to how software is developed, ongoing maintenance, and creating work processes capable of supporting innovation and rapid development is crucial. Vision to Value uses 5 pillars to support these operations; Vision and Strategic Plan, Work Management, Process Management, People and structure, and Data and Information Management.

This outlines a framework designed to support tech organizations as they scale, with the goal of creating a sustainable organization capable of delivering value to customers over the long-term,

Visit the book page

Introducing Vision to Value

September 11, 2019October 29, 2019
by Luis Gomes de Abreu

Today’s entrepreneurial landscape is booming with new ideas, concepts, and technologies. Modern business owners have more options and opportunities than ever before. This leads to startling statistics like the United States Small Business Association estimating more than 600,000 new businesses are launched each year in the U.S. alone. Despite this landscape of opportunity, an average of half a million U.S. businesses closes every year, and those statistics likely mirror the global market, where more than 3 million new businesses launch each year.

At the same time, many of these businesses have more help in the form of seed funding, Angel programs and accelerators than ever before. Most have a minimum viable product, many have a great deal of happy customers, and many are driving a profit. What goes wrong?

Marc Andreeson published “Software is Eating the World” in the Wall Street Journal in 2011 and today, it couldn’t be more relevant. Companies ranging from Amazon to tiny gardening startups are primarily selling software, and some don’t even realize it. More organizations than ever before are now tech companies. Rather than modeling, producing, and selling a single iteration of a project, tech companies must create structure to invest in continuous development and ongoing product delivery.

Developing a Framework for Tech Organizations

In Vision to Value, tech entrepreneur Luis Gomes de Abreu shares his framework for building the structure and foundations to successfully grow a tech company. Based on more than 10 years of experience as COO at Amsterdam-based payrolling company Nmbrs, as well as several ventures with startups like Grappster, the book covers the foundations of tech operations.

Luis began his journey in 2008, as a software engineer. When the opportunity arose to develop a new payroll/HR application, he took it. With limited industry knowledge and no knowledge of operations, he and business partner, Michiel Chevalier, built a new company. Over time, it became clear that if Nmbrs were to grow, it needed a strong structure to drive and support growth. Luis’s responsibilities shifted into operations, where he took on operations, internal operations like onboarding and customer care as well as introducing Agile into the organization. He quickly discovered there were no real solutions that met the needs of his company. He frequently had to create new solutions, reinvent new ideas, and experiment to find the best solution to a problem. He and his organization built everything from the ground up. Nmbrs took the Agile approach of taking small steps, testing everything, and using trial and error to discover the best solutions.

Over time, Luis developed a repeatable, structured framework, which he could apply, tweak to get different results, and control to sustain the quality and speed of software delivery.

Today, Nmbrs serves thousands of customers, who together serve hundreds of thousands of employees. But not every venture has been as successful. Startups like Grappster and WallyLabs helped Luis understand what doesn’t work, giving him the experience to pinpoint problems and why companies fail.

As Luis continued to work in the industry, he rapidly discovered that most organizations don’t have the structure or framework to support growth. Startups are often fronted by people with great ideas, but little knowledge of operational structure, especially for tech companies. As he continued to expand his own business and to experiment with others, he decided to create the Vision to Value Framework for others to use.

The Vision to Value Framework

In Vision to Value, Luis introduces a framework designed to support scaling tech companies. The book compiles the experience and strategy of 10 years of experience at Nmbrs and other organizations, helping business owners to bridge the gap between startup and scaling.

Here, the book introduces an operational model, complete with information on implementation and its impact on the organization. The framework introduces 5 pillars, which Luis uses to support tech organizations.

Vision and Strategic Plan
Work Management
Process Management
People and structure
Data and Information Management

Each of the pillars are designed around operational elements Luis found to be essential in tech operations. They can be tweaked and focused on at different levels to achieve different results, but must be balanced to achieve quality output.

These pillars each link to 7 qualities or outputs, which function as objectives and desirable qualities. The framework is intended to allow organizations to produce these qualities, resulting in speed, happy customers, quality budgeting, and others.

The book also balances theoretical and practical information, sharing high-level ideas that must be implemented for your organization and specific technical strategy tips. This applies to designing structure, organizing teams, and structuring the operational model to support growth.

Read the Book

Visit the Book Page