Whether you passively observe neighborhood construction projects or avidly consume This Old House (anyone else excited for season 42 next year?) most of us are familiar with physical building projects. You can look around your home or office and generally picture how a team imagined, designed, and built it from nothing.
Digital products, on the other hand, are a little harder to picture. The average American spends 24 hours a week online and the average Canadian isn’t far behind, but your average American or Canadian isn’t necessarily coding in their spare time.
So, how does a landmark digital product like SCOUT by Forager get built? How do we decide which cross-border bottlenecks we tackle first? Why did we add contracted rates and lanes before other, seemingly just as important features?
Let’s pull back the curtain on how Forager’s transforming an industry. And, more importantly, how you can get involved with the innovation.
How we build SCOUT by Forager
Step 1: start with a problem
We first launched SCOUT by Forager in October 2019. That initial release of SCOUT solved big cross-border shipping problems; problems we knew a lot about because we’re experts in cross-border shipping. We built an instant rate feature to eliminate never ending back and forth lane rate negotiations. We built a clear and simple Active Load page to replace confusing Excel spreadsheets. We made SCOUT easy to navigate so businesses could make load booking and tracking the shortest, rather than longest, part of their day.
But now that SCOUT is out in the wild, we have a lot more sources of feedback and ideas. We want to solve problems for all these folks.
SCOUT’s everyday users are one of the best sources for feature ideas. Whether they’re the COO of a major manufacturer, or an Import/Export Analyst for a boutique produce shipper, SCOUT users know what the portal can do and how much more it could simplify cross-border shipping management. Our most recent release includes contracted rates and lanes because the businesses we work with wanted exactly that. In fact, we even moved buttons and changed a few layouts based on customer navigation feedback.
We do a lot of SCOUT demonstrations for businesses in the United States, Mexico, and Canada. Each time we demo SCOUT, we learn more about what shippers want and need to streamline their supply chains. People who aren’t using SCOUT can still offer insight into their process and help us understand their pain points so we can make the platform work for a wide variety of businesses and industries.
We use and test SCOUT every day! SCOUT powers our internal TMS and allows us to build and manage our network more effectively. Even our team’s non-freight experts can provide feedback on intuitive design and copy to provide the simplest, easiest user experience possible. Whether you’re a logistics whiz or a freight newbie – SCOUT should work for you.
“The constant source of motivation for me as a Product Manager is the opportunity to make someone’s day a little easier. Whether it’s by helping them get organized, saving them time, or even just reducing their stress, I love hearing from our customers about their issues and identifying ways we can help. Let’s get on a Zoom and you can vent at me!”
Step 2: define the feature
Once we have a problem to solve, our product management team defines what the solution, or feature, should look like in SCOUT by Forager. There’s a lot of research and questioning at this stage. What is the root problem? Who experiences it? What is a SCOUT user’s goal? What do they need to achieve their goal? The answers to these questions (plus a lot of other specifications) come to define the new feature and its story, appropriately called a “user story”. There are dozens of books and articles about this art (and you can ask Todd for some recommendations while you’re telling him about your cross-border shipping woes) and a lot of methodologies.
Quite simply, we want to be able to tell the story of how the product fixes something for the user. You’ll see this in a lot of communications with Forager. There are examples in this very post! “By giving our user an instant rate feature, SCOUT by Forager eliminated the never ending back and forth lane rate negotiations”.
Step 3: prioritize as a team
Next up is a “grooming” session. The product managers share their feature user stories and the engineering team asks questions and gives feedback. This meeting has a few goals:
- Make sure everyone on the team understands the full concept of the feature
- Determine the effort and resources it will take to build the feature
- Discuss if/when that effort is worth the investment
Some companies struggle with the prioritization step, but Senior Engineer Chris Mendoza said the Forager team has found its groove. “We have a lot of folks in the space who really know what it takes to get us to the next level. What it takes to improve our customers’ experience. Our engineering team is fortunate to work with product managers who understand what’s a priority for our business and for our customers.”
Would it be cool if a freight meme appeared after you booked your load? Maybe. Is that as important as launching the carrier portal? Maybe not today.
Step 4: add it to the roadmap and (depending on the roadmap) start building!
If the full team determines the user story is complete, the product team uses the additional engineering feedback on effort and timing to prioritize where each feature belongs on the product roadmap. A product roadmap is exactly what it sounds like. It shows what features will be developed, when they’ll be developed, and when they’ll launch.
Then it’s time for the engineers to shine. Forager’s engineers use the stories to start writing the code that creates the buttons, connects the API’s, and the makes the complex logic that ties it all together into useful features.
Step 5: review, test, and test some more
Once a feature is built, the rest of the engineering team reviews it to make sure it meets all the product manager’s story specifications and code quality standards. “It’s a really collaborative process getting a feature reviewed,” explains CTO Matt Weber. “We’re checking quality, tests, and making sure it’s doing what it needs to do for our customers. It’s one of the most crucial steps in making sure we offer great solutions that function well and scale. It involves everyone on the Product and Engineering teams working together and it’s been amazing.”
Next, the feature enters the “Staging” part of its development. This is the feature equivalent of “batter on deck.” The product manager reviews the feature, tests it with the customer who requested it, or calls on a group of users to give their feedback. The feature should not only work, but also make sense to the user and behave the way they expect.
Step 6: launch!
Once a feature passes those final checks, it’s time to launch! The engineering team releases the feature and it’s now available for anyone to use.
Step 7: gather more feedback, because nothing’s ever truly “done”
Sometimes a feature has a small error or “bug” and the engineering team needs to fix it. Other times, users give feedback as they start using a feature more and more. This is where good digital products shine. Yes, SCOUT was built well to begin with, but SCOUT also grows and changes to better serve its customers. We want to make sure that what we released solves the problem we set out to solve. Customer feedback goes straight to our product management team and the “idea to feature to reality” process begins again.
Helping Forager build a cross-border shipping portal that helps you
We have ambitious goals to keep adding to and improving SCOUT as we create a digital marketplace for cross-border freight. But, not unlike cross-border shipping itself, making SCOUT successful takes a lot of smart people with a lot of good ideas and constructive feedback. If you’re interested in how SCOUT could help your business today, as well as how we could work together and improve cross-border shipping, we’d love to talk to you.