Foxbox Digital is an award-winning engineering-focused product development agency.

Inside the Box Foxbox Digital Blog

Versapay: Digital Payments Mobile Strategy

We worked with NSLC to move them from a paper-led organization to a powerful digitally-enabled ecosystem. This included the creation of a new custom streamlined and automated scheduling system, as well as a modern customer-facing mobile app.

How NSLC's Digital Transformation Improved Operational Efficiency

The National Student Leadership Conference (

) hosts hundreds of on-campus conferences to help high school students better prepare for College. NSLC’s goal is to help students make the biggest impact on their future careers.

As their operations grew to host thousands of students and parents at one of their many conferences, they struggled with communicating scheduling and event information. This resulted in delayed communication and labor-intensive operations work to keep their students and parents updated with the latest information while making sure events run smoothly.

To support their growth goals, we worked with NSLC to move them from a paper-led organization to a powerful digitally-enabled ecosystem. This included the creation of a new custom streamlined and automated scheduling system, as well as a modern customer-facing mobile app.

This resulted in increased student engagement and parent communication, improved operations efficiency, and higher Net Promoter Score (NPS).

Here’s how our digital transformation impacted NSLC:

Hundreds of Hours in Efficiency Saved Through Automation and Digitization

NSLC’s multiple-day conferences depend on a single resource—the schedule. This schedule provided the timetable of events and event information for students and their parents in formats such as printed paper, email, and megaphone announcements.

If any information changed, it would result in a manual effort from the NSLC staff to correct and update (think: hundreds of paper schedules, reprinted and distributed to students).

When you’re working 14-hour days, every minute saved in operations is a cause for celebration.

A new automated scheduling system, built from the ground up

The schedule was the core of the student experience. This told them where they had to be, when, and what they should expect in each event. By creating a new scheduling system from the ground up, we digitized the student scheduling system and automated the creation of the digital and printed schedules.

This scheduling system not only saved the NSLC staff a lot of time, but helped the organization coordinate with outside vendors and university partners.

A new modern mobile app built with React Native

The digitization of NSLC’s business resulted in significant operational improvements, resulting in hundreds of hours saved every month.

“The staff-side software made an exponential difference in how we work. It’s so much easier! Words can’t explain how big of an impact this was for our organization,” - Susan Lowitz, Director of Operations, NSLC

Automation of paper schedule modifications

When a schedule change happens, paper schedules need to be updated. Previously, the design team would need to be notified and changes were made manually, and all of the changes involved new email notifications and paper schedule changes, sometimes resulting in confused students. Now, the new digital system makes the design changes seamlessly and automatically.

In the new digitized system, changes happened in real-time and behind the scenes. With immediate access to their updated schedules on mobile and web, students and parents had the relevant information they needed to make every session count.

“We found that parents were checking in on their kid’s schedules and activities while they were on the train, or any down moment they had. The relevant information was getting to them much quicker, and that made a huge impact on our customers’ experience,” - Susan Lowitz, Director of Operations, NSLC

Students were instantly connected with their peers

Teenagers can be shy. Connecting with other students and making friends was not always an easy activity for them. We fixed this by connecting them with other students through the Group.me chat message platform they could access through the NSLC app.

Students were interacting with other students before they even attended their first event. Connections and friendships were made almost instantly.

Student Referrals Skyrocketed and Access to Student Feedback is Now Instant

NSLC relies on survey data to improve their conferences. Traditionally, they would distribute paper scantrons and students would hand write their comments. We saw an opportunity to collect more thoughtful survey responses, as well as an ability to collect more refined data.

Session-level feedback surveys allowed for more feedback than ever before

With the new digital platform, NSLC was now able to collect surveys immediately after a session was complete.

The operations staff had the flexibility to dynamically assign session feedback to many types of events. This resulted in immediate, personalized feedback that they previously weren’t able to capture.

A dynamic database that allowed NSLC to personalize experiences.

We created a dynamic database that allowed the staff to access their student roster, with access to information needed to personalize their students’ experiences. This included their contact info, emergency contacts, dietary preferences, information on their assigned staff, and whether they were on or off-campus. This easy to access database, allowed the NSLC staff to personalize each and every student experience.

Happier Students, Grateful Parents, and a Productive Staff Results in More Student Referrals

It was more than moving from paper to digital. It was about enabling NSLC to serve their clients. As a result of an improved experience, substantially more students invited their friends for the next conference season than they did last year.

More technology isn’t the answer to everything. In some cases, more technology is a burden and doesn’t solve your current business problems. We were cognizant of this as we focused on building a simple to use platform that allowed the NSLC staff to do what they needed to do with minimal training.

Students had a more seamless experience than ever before, parents were grateful that their kids experienced the NSLC without any hiccups, and the NSLC staff was able to do it more efficiently. That’s a win-win-win for everyone involved.

If you enjoyed this case study and you’re looking for a product development agency that can help you the same way we helped NSLC, 

How NSLC’s Move to Digital Increased Parent Communication, Student Engagement, Staff Productivity and Program Referrals

Kanban and Scrum are two of the most popular versions of Agile in use today. We have adopted a hybrid of both Kanban and Scrum as a successful framework for product development.

Agile & Scrum: How to Build Better Products, Faster in 2020

 is an iterative approach to software development that builds software incrementally instead of trying to deliver it all at once with an arbitrary deadline (as with traditional “waterfall” approaches).

Agile works by breaking projects down into little bits of functionality, usually called user stories, prioritizing them, and then continuously delivering them in short cycles called Iterations or Sprints. These cycles typically span one to two weeks.

Digital companies today rely on Agile methodologies to stay ahead of their competition and deliver innovative products to market faster than ever. But Agile is not a one-size-fits-all solution. There are various flavors and approaches to Agile transformation.

Kanban and Scrum are two of the most popular versions of Agile in use today. In fact, here at Foxbox Digital, we have adopted a hybrid of both Kanban and Scrum as a successful framework for product development.

In what follows, we’ll highlight the Agile tools, best practices, and methods we’ve successfully adopted to build innovative digital products that customers love.

Scrum and Kanban are two Agile methodologies we use at Foxbox Digital 

when building new products with React Native

The two methods share many similarities but also have some 

Scrum is a lean software development methodology that focuses on just-in-time delivery of functionality and managing the amount of work in progress (WIP). The key to our successful delivery of projects begins with our two-week sprint and proceeds through the full lifecycle of story-telling in a layout, within 

, where we build the user stories, story-point them based on an assigned numbering sequence (consisting of a Fibonacci sequence to estimate the size and complexity of a user story), and prioritize them across a Kanban board.

Two weeks for us seems to be short enough to develop in a very concise and iterative fashion with our features. But it’s also a long enough time to allow the engineers to build something that has real value.

Sprints are more than just cycles of development, we also have several recurring meetings around our two-week sprints. Before a sprint begins, Foxbox will host a Backlog Refinement meeting with the client to ensure designs are reviewed and ready, and we have a clear understanding of the business requirements for each piece of functionality.

Principle #2 — Manage Your Engineers’ Time and Let Them Focus on the Right Tasks

Engineers want to engineer, not sit in meetings all day or debate what feature should be built and when. To improve development velocity, managing your engineers’ time is a critical task. Here’s how we do it:

: The planning call will outline the goals of the sprint and discuss the breakdown of issues within that sprint.

: We queue up issues in order of priority and across a Kanban board. Our planning calls focus on the issues ready to go in “Current.” Any engineer can self-assign themselves an issue in Current, and our general rule of thumb is they work on issues from top to bottom.

: And now we introduce Kanban. We don’t hard-cut everything and say, "Okay, here are the 10 issues we need to do over the next two weeks." We like to ensure the developers know which activities are the most important. There is always an ongoing workflow, where priorities are continually ordered and updated.

Principle #3 — Simple Issues Drive Clarity (Avoid Complexity)

The goal is to drive clarity on what exactly needs to be built and how long it may take. The less confusion the better off everyone will be. To do this, we identify all the issues we’ve queued up and:

During a planning session, our engineers will agree on a level of complexity for each issue. That level of complexity is represented by what we call “story points.” Story points give us a way to track how much effort will be needed to create a feature and generally are not correlated with an estimation of time.

The reason we do not estimate time with story points is for the same reason a salesman cannot give an estimate for how many sales they’ll close in a month, because there are too many variables to account for when estimating.

The reason to use story points is because you can track how many a team does per sprint, and then take an average over a number of sprints to find their “velocity.” Velocity will tell us on average what a team can get done per sprint.

We track our total points for each sprint because having an idea of our historical velocity will give us context for what we can achieve in the current sprint and also manage project deadlines and expectations.

We adopt a Fibonacci sequence for point estimations (1-3-5-8). This is more of a democratic process. The team will typically vote and build consensus around the complexity of an issue.

We use T-shirt sizes, so a 1 is a small issue, 3 is a medium issue, and a 5 is a large issue. A 1 doesn’t necessarily mean 4 hours of work, some projects are much more complex and a 1 can take longer (or it could take less). If an issue is voted as an 8 or larger, that means it's our responsibility as a project manager to break it down into smaller iterative chunks.

Principle #4 — Use Kanban Boards to Harmonize Your Sprints

 goes from right to left, so this represents the flow of development:

Always look top to bottom for priorities.

QA review means it’s done and ready for user testing.

Principle #5 — Create Your User Stories to Answer “Why Are We Building This?”

 are ways to describe features that customers might like to see in their software. A user story describes the type of user, what they want, and why. In other words, user stories are a starting point to a conversation that establishes the real product requirement.

But why can’t we just give a simple statement for what to create instead? Well, here are some examples of why that does not provide the same information and flexibility as a user story.

This statement is too big/vague. It does not provide any information except that a sidebar menu is needed. We should also be answering the following questions:

The sidebar needs to expand over ¼ of the screen, with a quick animation and color change while the sidebar is opening.

While this statement provides more information, it is not valuable. It does not answer key questions and makes critical assumptions that may prove problematic later on. We should be answering the following questions:

Again, who wants this? Who is the target user?

Does the user care that the sidebar expands across ¼ of the screen as opposed to ⅕?

What if ⅓ makes more sense due to what the sidebar is going to contain?

Does the user care about the color change while the sidebar is opening?

User stories are useful exercises. They help ensure you’re writing stories that deliver value (if you can’t achieve a value statement, check if you have a really good user story). The stories remind engineers about “Why are we building this?” If you can’t write it as a good user story, is it ready for development?

For every value statement, we assign it a short title. We use this format for every value statement: As a ___, I want to ___

So, let’s say we wanted to build out the sidebar navigation. One potential value statement would look like this:

Even though this follows the convention for how to write user stories, this does not contain any valuable information. We should be answering the following questions:

What kind of user wants this? Who is doing the action?

What value does opening the sidebar provide?

Why does the user want an easy-to-access menu? Is the current menu hard to access?

Can the user’s issue be solved with an easier solution?

Instead, a better value statement would look like this:

This user story provides an enormous amount of information in a simple statement:

But let’s take this to the next level. Here’s a fully defined value statement:

expand the side navigation and easily find any category

I can order what I need more quickly and not search for it

This user story immediately gives you a wealth of information:

What role the user plays in this app, as well as what role they play more generally, which allows us to better work the feature for them.

The action is paired with what it needs to accomplish and includes what the menu needs to display.

The user’s stake in the feature is also clearly laid out and addresses the pain point it solves.

Each story also contains tasks and acceptance criteria. Tasks typically consist of a checklist filled out by the engineer. These are tactical things that need to be done to complete an issue. Acceptance criteria (also called “business requirements”) are the most important part of the “user issue” phase.

: QA will go through the task checklist themselves and make sure this feature does the following things. It looks something like this:

The sidebar menu needs to expand over ¼ of the screen.

There needs to be UI for placing orders (i.e., the shopping cart icon and text).

There needs to be UI for driverless runners.

Create Your User Stories

Principle #6 — Measure Progress (Sprints, Tracking Velocity, and Burndowns)

It’s important to know how we measure progress. We’re using GitLab to setup sprints, which is how we track our sprints. We will add issues to each sprint and monitor the progress, so you can see the burndown chart for the sprint fix. GitLab serves as a good little analytics tool for tracking your burndown.

 — Shows where you are in a sprint and where you should be. We track points closed for every sprint (i.e. two weeks). Sprint 1: 10 points. Sprint 2: 15 points. Sprint 3: 7 points. By using a rolling average (i.e. right now it is ~10 points), that's what we expect to see in our current sprint. Velocity becomes a lot more valuable after a few sprints by helping us understand what’s working and what’s not, as well as give an estimate for how much work we are on track to complete per sprint and beyond.

 — If tasks don’t get done, they roll over into the next sprint and get reprioritized. But it's very rare if we haven't finished something that I would deprioritize it because it was prioritized for a reason (so we just continue on to the next sprint handling that issue).

Each recurring meeting is an important part of Agile development. While in pure Scrum all meetings are held within a sprint, one of the meetings we do after is called a retrospective, or a “retro.” A retro allows the team to reflect on what we did really well, what we did not do so well, and how we can improve.

It's an internal meeting because we want the team to feel they’re in a safe place to share their thoughts about progress or things that have hindered them. It's kind of a knowledge-sharing session where we talk about process improvements.

Principle #8 — Communicate Early, Often, and Consistently

We send weekly updates to clients, and they can always access us on Slack. We want them to know they can communicate with us directly whenever they need to. We also host a bi-weekly meeting, usually in-person, with the client where we demo our progress and elicit feedback.

Our meetings often turn into a prioritization meeting. We discuss what was done, we show-and-tell features, we have them test live with us, we get some feedback in real-time, and we put together a game plan for future sprints.

In the “old days” of waterfall software development, user features were scoped out upfront, requirements identified, and then everything was handed to engineering teams who would deliver back, after several months, a complete app that everyone was sure the customer would love. But without testing and iterating on feedback during the process, the "finished product" would often land far off the mark.

Discover why more and more companies are choosing React Native to build innovative digital products.

Why CTOs Should Choose React Native as Mobile Platform

I’ll be honest, for the first eight years after iOS was released, building an application natively within iOS made sense and was the only proper decision to make. 

 had promise but lacked many core features and UX experiences that it didn’t make sense to switch over.

Native apps are considered the gold standard and offer the best overall performance, user experience, and access to hardware-related features such as support for multi-touch gestures, access to the camera, GPS, calendar, accelerometer, and much more.

But now the mobile world has moved on and React Native is the right decision for many companies.

React Native has transformed the whole dualistic notion of iOS vs. Android by creating beautiful apps for both platforms from one codebase—without compromising on the UX and UI. On a React Native app, everything you see and touch is native.

So unless you are Uber or Airbnb and can afford to spend money and time on exclusive native mobile development, your business really should be using React Native as its development platform of choice.

The reason is fairly straightforward. With React Native, you have a best-in-class framework that is optimal for 95% of all business use cases.

React Native is especially good news for CTOs and VPs of Engineering because instead of hiring two additional development teams for Android and iOS, you can leverage your existing web development team to build your mobile app. React Native represents the best organizational choice for CTOs and VPs today.

I didn’t want to start with this because I don’t think “

” is a valid excuse, but the maturity of React Native makes it an easier business case for your organization.

React Native was introduced in 2015 and underwent the initial stable release in July 2019. Over the past four years, it has become a robust worldwide open-source community with over 

 contributors on GitHub—and, of course, with the backing of Facebook. It’s also the 

 of contributors for any repository on GitHub in 2018.

React Native developers are continually building new libraries, updates, and projects. With cross-platform compatibility, shorter development cycles, faster releases, live code pushes and updates, and overall performance improvements, many have come to see React Native as the future of mobile development.

Facebook originally developed React Native as a hackathon to support its cross-platform needs. The beauty of React Native is that, unlike “hybrid” mobile app solutions, it uses native UI elements instead of rendering the entire application inside of a WebView. Your business logic is run in a separate JavaScript thread, which then controls the native UI elements. In the “old days,” companies had to develop native apps for both Android and iOS from scratch.

React Native allows developers to write code in just one language, JavaScript, then build binaries for Android and iOS. It eliminates the need to hire both iOS and Android developers to write dual applications, and this represents a huge benefit in terms of productivity, costs, and time to market. Not to mention the reduced hiring burden!

As a CTO, you’re most comfortable managing a company you understand. If you happen to be an Android “guy and need to hire an iOS developer, you’re not speaking the same language and have to work extra cycles to get everyone on the same page. This can easily lead to operations hang-ups and production slowdowns.

Being able to write once and port across each major platform means a considerable improvement in the operation of your organization. The ability to place resources on different projects and not have to worry about skillsets and whether a developer can write Swift, Objective-C, Kotlin, or Java is a huge relief.

Nearly 67% of all developers use JavaScript already, so it’s an easy sell for using React Native to improve operational efficiency across the enterprise.

There are many ways React Native saves organizations time and money. Obviously, the “one code for all” is a huge advantage as it cuts down on the learning curve and the number of hands on deck required for developing an application. It’s also open source and has a robust and growing community of ready-made components and support.

In fact, something like 95% of the React Native codebase is shared between iOS and Android. These are just some of the many reasons why React Native leads to significant improvements in ROI over hiring native developers.

As good as React Native is for all-around performance, cost savings, and portability, a few use cases will stand out that require a pure native look and feel. These are going to be the high-end enterprises, such as Airbnb and Uber that have money to spend on super-polishing their native application.

For the “rest of us,” which means 90%-95% of the business use cases, React Native will provide your organization with a highly engaging enterprise application. In other words, the reasons for not using React Native are going to be negligible.

In terms of cost-savings, increased efficiencies, and the overall native look and feel that users experience, React Native is a no-brainer!

Yes, not every app should be built with React Native. Here are some reasons to go full native:

You’re creating something with complex animations and interactions, like an interactive game.

You’re building something that’s CPU intensive, like editing photos. In that case, you could either go full native or write the complex logic in native and bridge it to React Native.

You’re creating something out-of-the-box with unconventional UI patterns. Native might be a better choice in that case.

For CTO’s, quickly getting the right products to market is all that matters. As a “learn once, write everywhere” framework, React Native cuts down enormously on the cycles required to develop and deploy user-friendly and engaging products to market. React Native is arguably one of the biggest breakthroughs in mobile application development in recent years.

, this cross-compatible platform has transformed the way companies develop enterprise-grade applications—with less learning curves, shorter development cycles, faster releases, and overall cost savings.

We’ve been using React Native since I founded the company and aren’t looking back anytime soon. You can learn more about our React Native development services 

P.S. If you’re trying to decide between React Native and other cross-platform mobile frameworks, 

Why CTOs Should Choose React Native as Their Mobile Development Platform

Nearly all business executives today believe that Agile is critical to business success. If you’re launching a digital product (or considering one) then you won’t want to miss this recent podcast on Enterprise Radio where our CEO Rob Volk discusses why more and more companies are choosing Agile and React Native to build innovative products. 

The Agile and Mobile Revolution with Rob Volk, Founder of Foxbox Digital

In July 2017, Forbes interviewed more than 500 senior executives from around the world, and 92% said they believe organizational agility is critical to business success. If you’re considering a digital product or roadmap, or are just curious about what Agile is and how it helps companies grow, then this podcast is a must-listen.

I sit down with Eric Dye of Enterprise Radio

 to talk about Agile and why more and more companies are adopting this transformative approach to mobile development.

Please listen to the podcast in the link above, and for those that like to browse ahead, check out our show notes.

1:49 — My goal in building Foxbox Digital was to help large companies build with the agility of a startup while using modern development practices.

2:15 — React Native is a really phenomenal cross-platform mobile framework and the reason I like it is because I think it's well-suited to 90% of the apps out there. It's something that gives you the benefits of cross-platform so you have one code base and one team building for both iOS and Android.

3:47 — Typically, the reason companies decide they need Agile is because they’re experiencing some symptoms, such as late project delivery or reliability issues that come up during the integration phase (or worse, when the product has gone live).

4:53 — In order for Agile to work for everyone, the entire organization has to be bought in. This means the UX folks, the product owners, the developers, DevOps, etc. must be brought out of their silos—so everyone is bought into Agile from the start.

5:36 — What doesn’t work with Agile is to just choose one group, say your UX team, to adopt this approach. It must be all or nothing.

6:10 — In order to do real work, you must have an extended period of time of uninterrupted focus. That's when you can really get your “deep work” done—things that matter.

6:40 — So Slack is a perfect avenue for people to interrupt you. It's become part of our culture for people to expect immediate responses. But that's unfair to you because that prevents you from doing actual work.

When I received the final design spec to build the internal portal for a large pharmaceutical company, I knew something was wrong.
The design spec was 1,000 pages long, and it took the team 2 years to create, one year more than they planned for. It had every feature request imaginable in it. Since the original project scope was fixed for 3 years, this only gave us (engineering team) one year to create it. Two years to design and one year to build a product isn’t an ideal situation.

Agile Product Development: Build An Amazing Product in 2020

When I received the final design spec to build the internal portal for a large pharmaceutical company, I knew something was wrong.

The design spec was 1,000 pages long, and it took the team 2 years to create, one year more than they planned for. It had every feature request imaginable in it. Since the original project scope was fixed for 3 years, this only gave us (engineering team) one year to create it. Two years to design and one year to build a product isn’t an ideal situation.

Try to build it exactly the way it was designed. Work overtime, hire more people, and do a rush job to make everyone happy. Ultimately miss our deadline anyway because it isn’t even close to being feasible.

We could come back to leadership with reality: We couldn’t build this in a year. Not only that, even if we could, it wouldn’t make sense.

We chose option 2, and the business team resisted as much as they could. In their minds, everything was critical, nothing could be cut. Through several important “reality check” meetings, we ended up getting our way.

The result: We cut 80% of scope. Yes, 80%. It turns out the critical features they wouldn’t remove weren’t actually that critical at all. We built it within a year, and although it was a successful roll-out in the end, the way this project was run from day one left a sour taste in everyone’s mouth.

I learned several key things from this project:

If engineering, DevOps, design, and business teams aren’t one unit, then everyone is wasting their time. It makes large projects almost impossible.

Keeping engineers coding and not waiting should be a higher priority. On top of the impossible timeline, we were working with siloed teams. When we needed a simple change from the UX team, we'd get it back in two weeks. What are we supposed to do in the meantime?

For the next 10 years, I’ve spent every waking moment helping organizations (large and small) 

bring Agile product development to their organization

. And my goal with this guide is to give you a better idea of how enterprises can adopt an Agile mentality when it comes to building and deploying products.

I’ve had the lucky opportunity to be part of building many digital products from the ground up through my enterprise consulting career and my experience as a CTO for two successful startups, and now my digital product agency, Foxbox Digital.

I’ve been able to help Fortune 100 clients, including Pfizer, USPS, and Morgan Stanley build and scale enterprise apps using Agile and by defining strong product strategies. As the CTO for several startups, I led the technology and product teams to scale to hundreds of thousands of users and tens of millions of dollars in revenue.

The secret? It all started with a strong digital product strategy. I’m going to share my thoughts on how to create a digital product strategy in 2019 and include little tidbits, like the story above, on how I failed and also how I was able to make better product decisions, consistently.

I also want to preface this guide with the obvious: “Startups often get it wrong.” So, blindly telling enterprise companies to do it the startup way isn’t sage advice. The goal of this guide is to help educate you on the successes and failures of startups, and how to get your products to market faster.

At a previous startup I was part of, we followed the Lean Startup methodology by the book. We got out of the office and spoke to customers face to face, and asked them what they wanted.

We got validation of the product every step of the way. Everyone loved it. We launched with a lot of fanfare. We were published on all the major tech blogs like TechCrunch, Mashable, and Venturebeat.

The users came to download our free product. By all measures, it was a successful launch. We did the math and free wasn’t going to pay the bills.

We made an educated decision to make it a paid-only app and completely removed the free version. We warmed our customers up for the transition. It wasn’t a surprise by any means. They knew the free version wasn’t going to last.

We figured since so many people—during our customer interviews—said yes to the “Would you pay for this?” question, that switching to the paid version when available will be a no brainer. Then it became obvious. Users never signed up for the paid version, even the customers that told us directly they would. Our product did everything they asked it to do.

Either they were liars, or we did everything wrong. As you might have guessed, we did everything wrong.

The purpose of this guide is to tell you what my previous startup did wrong, what we would do differently, and how to create an effective digital product strategy in 2019 so you can avoid the simple mistakes.

To start, I think it’s important to understand what separates a good product from a great one. Some differentiators I’ve picked up over the years are simple to understand, and some are nuanced.

The goal is always to build an amazing product, not just a good enough product.

If there was one term that irked me to no end when working in enterprise was “This is good enough.”

Good enough used to be sufficient. Now, good enough means a loss of revenue, lost market share, and any other business metrics you can think of. Don’t set the expectation that just because you work for a big company that good enough is okay.

Here is a simple framework to determine the difference between good and great products.

Great products solve problems in a way that’s intuitive, brings you joy, and strikes other positive emotional response when using it.

Here are a few examples of great products that come to mind:

Additionally, Here are more attributes I’ve seen from great products.

Growth Marketing is built into a product, it’s not an afterthought.

Meaning, the product grows from word of mouth, or a network effect, from purposeful features built into the product to make it grow.

Slack (invite your team, it makes perfect sense), Hotmail (check out hotmail signature).

A quick side note and a word of caution: I’ve personally seen how products went viral because of these built-in growth features, but then users churned really quickly after engaging with the product. So, yes, growth built into a product is great, but to keep up that momentum, the product must focus on the core use cases and solve a real problem.

The product was built around one or two core use cases. It doesn’t try to be everything for everyone. It does one or two things exceptionally well for a defined type of person.

Inside the Box

Articles, updates, and ideas you can put to use.