We’ve been a remote-first company since day one, and it’s helped us attract and retain some of the most talented designers, developers, data scientists and project managers from across the country. We only hire highly motivated individuals with excellent communication skills. Because we designed our company as a remote workplace, we’re able to give clients a seamless working experience, even though we’re not onsite.
Every client engagement is a highly collaborative partnership. We work fast, and it’s crucial to have consistent check-ins with our clients to make sure we’re always working on the most important things. We use video conferencing to have face-to-face interactions with each other and with our clients. Because we have a tightly defined communication cadence with our clients, our customers feel just as involved in the development process as they would if we were on-site.
To ensure that our work style is at least as effective as working together in person, we have a code of conduct that all Very team members adhere to. The Code of Conduct includes:
Each team member is responsible for having a distraction-free workspace, whether they choose a coworking space or have a home office.
To make the video conferencing experience as seamless as possible, all team members must have access to at least a consistent 5Mbps connection.
Our core working hours are from 9 a.m. - 5 p.m. EST. We work with clients for 32 high-quality hours/week, reserving the remaining 8 hours for professional development and internal projects.
Your Very team will be available to you for active collaboration during regular business hours. We’ve tested many different collaboration tools, and we only use the best of the best. Here are the five must-have tools we use to collaborate with each other and with our clients.
For a typical client kick-off, we have team members fly out for an in-person Product Strategy Sprint. We put together a tight agenda in advance and typically work a couple of full days together. Our product managers are also available to come onsite for additional Product Strategy Sprints on an as-needed basis.
"Very was truly our partner in launching Thrive Global's digital media presence. In a short time-frame, they designed and problem-solved alongside our team seamlessly. They are flexible, creative, and focused on quality."
We begin by learning everything there is to know about your business, your customers, and the problems this project will solve. We also identify unvalidated assumptions and knowledge gaps, so we can start managing uncertainty. From there, we make plans to fill the riskiest knowledge gaps and validate, or invalidate, the riskiest assumptions. We also review all existing research and conduct an analysis of competitive products.
During a project kickoff, we go through a rigorous Product Strategy Sprint process that takes place over the course of several days. Throughout the sprint, we work to define the business needs, the end users, and the solution we're bringing those users. We identify the situations in which they will use the product and its features, and we determine their motivations. Together, we decide what success looks like — for the whole project and for customers.
The goal of a Product Strategy Sprint is to:
The next working session is about getting to a finer level of granularity and talking about specific features. This is where the rubber meets the road and we begin to ground the concept. Together we work on an exhaustive list of user-facing features, necessary administrative functionality, and general platform foundations. For this activity, the goal is to determine which features are critical to the business and customers, and this helps us start thinking about how to define the Minimal Viable Product.
The session starts with everyone creating cards, in person or virtually, and placing them where they feel the cards fall in priority. The three choices are:
Once everyone has completed the first task, we process every card as a group. This is where it's critical that all stakeholders are collaborating. We want to meld the viewpoints of engineers, designers, domain experts, and product owners. We'll reorganize everything, write new cards as needed, throw cards away and ultimately end with a high-level roadmap for the project. We'll record all these cards on the Pivotal Tracker board, which you'll learn about later.
Each project has its own unique concerns and constraints. We do our best through this process to identify potential bottlenecks and roadblocks as early as possible. Oftentimes, this comes in the form of evaluating some external service or piece of software, but as your product complexity increases, we will need to do Research Spikes on the riskiest pieces, which may include:
We take whatever time is necessary to dig into the specifics here and put together some initial suggested paths forward.
Job stories are the fundamental units of functionality we build and deliver. We think of them as vertical feature slices that stand on their own and add value to the end user. Job stories define a given situation, a user's motivation for acting within that situation, and the expected outcome of the action.
Using the "Jobs To Be Done" framework, we walk through the Job Stories, key activities and flows that users will take through the application. Then, we assemble them into a working list and prioritize them. This is a crucial step in defining the user experience and user interface, and it heavily informs the overall design of the application.
After we draft stories needed to accomplish user goals and business objectives, we estimate each job story with points. Points indicate the complexity of various job stories, as well as supporting details. We break down more complex stories into smaller ones, reducing exposure to risk.
This provides us a clearer understanding of how much effort is required to build the pieces of the application. We also account for system concerns such as performance, compliance, scalability, fault tolerance, and maintainability. During development we will learn much more about how to build solutions to meet users' goals, so we will continue refining stories and our roadmap.
At this point, we look holistically at development needs. We build out a product development roadmap, organized into releases and weekly iterations so that the coming releases are clearly defined. We construct a release plan by sequencing work based on technical dependencies, risk, resource utilization, and just-in-time planning.
We've turned over most stones, and in some cases, performed research spikes to reduce uncertainty and verify assumptions. At this point, we should have a decent idea of what it will take to bring your vision to life. We will provide you with what we believe is your best path forward, along with some timing and cost estimates.
Pivotal Tracker is a task management service and the backbone of our workflow. All work that needs to be performed is represented on a Pivotal Tracker Story. Stories can have task lists, attachments, and conversation threads. They are grouped and organized to fit the evolution of your individual product.
At the end of our Product Strategy Sprint, we look holistically at development needs. We build out a product development roadmap, organized into releases and weekly iterations so that the coming months are clearly defined.
Your team will work an average of 32 focused hours per week, and they will be dedicated solely to your project for the entirety of our engagement. By working with the same team day after day, week after week, we’re able to reduce waste and increase efficiency to keep your project moving forward at a fast and predictable pace.
One of our senior team members will serve as your product manager and primary account manager. During your Product Strategy Sprint, we'll determine if they need to serve in a dedicated capacity, working only on your project, or if they can be effective managing your project in addition to other client projects. Their role is about driving the project forward. By providing unbiased product development insights, they will serve as your advocate throughout the development process.
Depending on your project needs, your team will be a tight-knit group of:
User experience (UX) designers are a critical part of modern application development. But too often, UX designers create a mockup, hand it off to developers and move on to the next project. At Very, our UX designers are also front-end engineers, bridging the divide between design and development.
Our full-stack engineers work in teams of two using a process called pair programming. This approach leads to better quality, fewer defects and greater levels of overall efficiency over the lifecycle of the project. It also gives every project an added level of redundancy.
With the increased popularity of artificial intelligence, big data, and machine learning, we've found that many clients need dedicated data science engineers to be responsible for data strategy. This role can be responsible for crafting data acquisition strategies, defining internal workflows and applying state-of-the-art technologies and techniques to your project.
We get a lot of questions about the way we work. The most common one is, "Do you have full-time employees or do you rely on contractors?" We are a US-based company with a team of full-time employees located all over the United States and Latin America. We believe in the team and culture we've built, and having full-time resources is crucial. In some circumstances, we will encounter aspects of projects that are better suited for a specialist or another agency. If this happens, we'll be the first to call it out, and we will work with you to make sure the project is properly resourced.
Instead of planning every detail of a product at the beginning of the project, we allow for changing requirements over time. This approach relies on deliberate, consistent feedback from our clients. To ensure we're always on the same page, we have a set meeting cadence that we follow rigorously for each project.
Daily: 5 minutes, optional
Each team member says what they worked on the previous day, what they plan to work on that day and if they have any blockers. This meeting is highly structured and intentionally kept short. Any blockers or issues raised during the standup will be triaged by your product manager after the meeting. You are welcome to join daily standups, but they are not mandatory.
Weekly: 40 minutes, required
During an Iteration Planning Meeting (IPM), your team will determine how much of the backlog they can commit to delivering during the upcoming iteration. In order for your project to go smoothly and meet your expectations, we need a designated product owner from your team to attend every IPM. You can expect planning meetings to occur each Monday and last less than an hour.
"At the beginning of our engagement, I thought, 'Meeting every day is going to be tough. And how much benefit am I going to get from being involved?' But after the first week, the benefits were obvious."
Weekly: 30 minutes, required
After the iteration ends, the team will present working software and work-in-progress in order to demonstrate value delivered and obtain product feedback. We then assess how this iteration advances us towards our current release.
Weekly: 30 minutes, optional
Before planning the next iteration, we reflect on how we worked together and how we can improve our effectiveness as a team. We proactively identify and solve problems to improve performance.
Our highest priority is to deliver valuable, working software in a predictable way. We believe customers should be able to change their requirements, even late in development, because their business environment is constantly changing.
The best products are built when business stakeholders and product teams work in a highly collaborative way. For all of these reasons (and many more), we strictly adhere to an Agile software development approach.
Agile software development is an approach that’s based on making incremental improvements to a product with frequent cross-functional check-in points. Instead of planning every detail of a product at the beginning of the project, the Agile methodology allows for changing requirements over time and relies on constant feedback from stakeholders and end users.
With Agile development, cross-functional teams work on an iteration — a single development cycle — of a product over a period of time. Work to be done is organized into a backlog, which is prioritized based on business or customer value. The goal of each iteration is to produce a working product.
When using an Agile approach, business stakeholders and the product team must work together to align the product with customer needs and company goals.
The concept of lean software development emphasizes optimizing efficiency and minimizing waste in the development of software. The approach has its roots in the lean manufacturing movement, but is now considered a key part of the Agile software development methodology. Lean principles aim to streamline every part of the software development lifecycle, centering on the idea that less is more.
Extreme Programming (XP) is a disciplined approach to delivering high-quality software, quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing and planning, and close teamwork. Software is delivered at very frequent intervals — typically every one to three weeks. Ultimately, XP creates flexibility for changing business and product needs. It provides insights into the cost and time to build out features and deploy them.
We practice pair programming (sometimes simply called “pairing”), an agile software development technique where two programmers work together at a single workstation. One, the driver, writes code while the other, the observer, reviews each line of code as it is typed in. The two programmers switch roles frequently. While it may seem like an ineffective use of resources, pair programming can increase project velocity because coding mistakes are caught and fixed immediately.