Questions For This Week

What would a test run of the program look like outside USASOC?

Who among our existing contacts can help us with another kind of test run?

What does USASOC need from us to have a more complete timeline on deployment?

To what extent will we need to be involved with USASOC once we reach the deployment stage?

What We Are Testing

• Our program generates enough interest from DoD entities to spur action.
• Our program is functional enough to manage our correspondence.
• Our program has a clear path to business viability.
• We understand what data we need to pull from USASOC’s databases in our deployment.

Key Insights

From a USASOC deployment standpoint, we were able to confirm that many users are as interested in AARs and SITREPs as they are in things like trip reports and RFOs. We also developed a better characterization of what these forms are providing. There is still no formal process for identifying a problem at the outset, trip reports cover available options, SITREPs cover a project’s timeline, and AARs cover the end results of field testing and deployment. We also informed our problem sponsor that a testable prototype is imminent and are awaiting his response as to what next steps will be.

From a wider DoD standpoint we are still exploring the potential to deploy with a unit like AFWERX following our test run with USASOC. However, our conversation with Mike at DIU offered us some insight as to what our endgame could be if we focus on deploying within DoD. According to Mike, DIU currently deconflicts projects with 70 entities across the department and largely does so manually with phone calls and meeting. He acknowledged the challenge of trying to deploy this kind of solution at such a scale but was surprisingly optimistic about it. He felt that if we could get individual buy in from these entities, then the technical challenges associated with connecting them would not be so difficult to overcome.

From a business viability standpoint, Dr. Jared expressed some skepticism as to whether this program can differentiate itself enough from what is out there to avoid getting crushed by established competition. To succeed as a business, we will either need to be able to find that clear differentiating factor that delivers clear value or find a customer niche large enough to sustain our business but small enough to avoid attention from the largest competitors. Our discussion with Akber also indicated that our particular method of deployment, while it could be a differentiating factor, is also likely to be more expensive from a deployment standpoint than a cloud solution, particularly if our aim is to expand to the commercial sector.

Interviews (10/122)

Akber – Fire Engine Red

• His system is cloud based, so if we are deploying on site it may be more costly.
• Sales team can generally manage 6 clients per person at a given time.
• Deploying a product with a client typically takes about 3 months and the equivalent of 1.5 monthly salaries between sales and tech.
• Tech also manages troubleshooting and maintenance, maintenance is much lower cost than rollout.

Brian – Squadron F

• From a collaboration standpoint, he’ll do so with his team but also with 5-6 other offices whose projects might have technical or operational overlap.
• In particular, he wants to be able to easily collaborate even when the other team might physically be halfway around the world. For an operation it can be for weeks/months, for a longer term development it could be over a year.
• Right now that is accomplished with emails and in person meetings. Can be difficult to get everyone in the room at the same time due to packed daily schedules and frequent travel.

Alex – BMNT

• Expressed interest in our project.
• Believes that there are pathways to move it forward, either via MD5 or some other DoD program.
• He will go and see what could be available to us and circle around with next steps.

MSG Darrell – R&D Section Leader

• The way I want CDD involved in my projects depends on the project itself, which is why I would want to have some choice of how much access each user or shop has.
• In some cases I’m tied in from the beginning, which could include going on trips on their behalf and reporting back.
• In other situations, I will only tie them in when I need access to a specific funding line.

Dr. Jared – Course Advisor – BMNT

• Believes we identified “an interesting set of needs.”
• However, is also concerned about the competitive landscape as it pertains to the program’s business viability.
• To make a business out of it you’ll have to really connect with a customer OR identify a segment that’s profitable for you but too small for you to get crushed by a giant competitor.

Mike – DIU

• Project deconfliction is an increasing priority, as is collaborating across the ecosystems that populate DoD.
• There are 70 entities in the innovation space, all working to deconflict. Many have direct overlap with our portfolios. Weekly or even daily we will meet with them to deconflict and we regularly get questions from appropriators on how we will deconflict.
• We also like to shop successful prototypes around to give other agencies a chance to jump on.
• Some sort of automated tool to manage this external process would make life easier, however we are confident in our internal process and don’t feel it would be as helpful in that context.

Nic – Squadron R&D Deployment

• The best data points for our purposes are the application pieces coming from the end users in squadron, often in the form of sitreps and AARs. However, there is no uniform method to submit this kind of info.
• SITREPs are like living documents, designed to keep everyone up to date on projects.
• AARs are more like end documents/statements, saying we went into this with X intent, what we want to sustain, what we want to change.
• Other types of data that is useful: what environment the tool is applied in; consumer purchase methodology (easy to use? need training? size, weight, power).

Tim – NSTXL CEO

• In his experience, meeting the military where they are when it comes to workflows, processes, and cultures is the best way to move projects forward.
• That said, if they are buying in to your system then they’ll take some suggestion on how to use it.
• Offer some best practices with the program but don’t expect everyone to behave that way. Don’t bother with rules, they’re only going to follow your guidelines if they think it will be useful.

SGM Angel – CDD – Future Concepts

• The critical squadrons from our perspective are Signal, Intel, and H. That is where much of the emerging tech exploration is taking place.
• Also engage with F and G – they are nice to have and not irrelevant.
• However, you need to make sure when you are using terms that are not standardized in the military that everyone is talking about the same thing.

Dr. Jared – Course Advisor – BMNT

• Having a good idea for a program is just the start when we are talking transitioning to business. You have to execute it and find something that makes users want to adopt it.
• Often that something is a behavioral insight that isn’t core to the tech itself. The best executed tech doesn’t always have the best users.
• While better execution will help you in some places, if you want to grow your user base to a level that is sustainable as a business, it has to enable people to do something that they could not have done in that way before.

Hypotheses Confirmed/Debunked

• Partially Confirmed: Our program generates enough interest from DoD entities to spur action. This week offered further confirmation that other DoD entities recognize USASOC’s problem as relevant to other units and are interested in helping us build the program. However, we have not found any new units (other than the ones mentioned in previous blog posts) that expressed interest in a test deployment of our program. We are confident we can get people’s wheels turning, particularly in innovation spaces like AFWERX, but less confident in exactly how far that will take us.
• Partially Confirmed: Our program is functional enough to manage our correspondence. To test our program’s functionality, we loaded all of our beneficiary interviews onto the platform to make sure we could easily add them and search them. While not fully functional, this transition was largely successful. However, it was a small number of files and applied by the person who created the program, so it’s less clear whether that ease of use will translate to the end user experience.
• Partially Debunked: Our program has a clear path to business viability. Our interviews with Dr. Jared made it clear that even though our program could be highly effective, we will likely need to find a clear differentiating factor that separates our program from all the others in the field to be a sustainable business model. As such, we don’t see this week’s interviews as totally dismissive of our potential, but rather that we will likely need to take more concrete steps to demonstrate value to the end user. Dr. Jared’s suggestion of finding a small niche isn’t totally unrealistic either – if we succeed in deploying at USASOC where other software failed that could be indicative of our ability to make this kind of program work within a government space.
• Confirmed: We understand what data we need to pull from USASOC’s databases in our deployment. It seemed almost every week we heard about some new potential source of data from which we could draw. But this week’s interviews with our direct beneficiaries showed that we seem to have a handle on the key types of information that end users care about. We were also able to clarify the timeline our end users have in mind when trying to access different types of forms.

Questions For Next Week

Now that the prototype is ready, when can we start testing?

What level of access will we have to deployment data?

Can we adapt our program to another unit’s workflow or is it too specific to USASOC?

What is our most viable path for further deployment of the program? Should we pursue niche government innovation spaces or the business sector?