I have recently been discussing my product philosophy with a few people and I’ve crystalized a few things into my personal product philosophy.
TL;DR: Most organizations don’t empower their SMEs enough and require the dev team to be part of the solution. I think this is a major mistake. SMEs should be able to impact the solution via prompts, rules/logic, workflow, & maybe even the data structure without the dev teams involvement.
What are SMEs?
SMEs aka “Subject Matter Experts” that live inside of your organization and your customers organization.
Let’s evaluate the typical process by which SMEs can translate their desires into product when working with an agency (or requesting a feature from a vendor). The SMEs document their requirements and understanding. Then they talk to the Product Managers about their desires. The Product Managers then translate these requirements to the dev team. Then the dev team translates these requirements to code. Then the QA team tests the code. Then it’s released and the SMEs can test the code.
But there is another way…
and it is ENTERPRISEY…
In most enterprise solutions, there exists solutions for SMEs to build solutions for their organization directly in the tooling.
This can look like:
- a rules/logic engine
- a workflow solution
- a dashboard builder
- a report builder
- tables/grids
- a prompt management system
- admin pages/panels
- saved filters/views
- the ability to add or customize fields (existing tables)
- the ability to add custom tables
It turns out there A LOT of benefits to empowering SMEs:
- It’s faster.
- It’s cheaper.
- It requires fewer deployments.
- It shifts the burden for the process to the SME vs the product & engineering teams.
Let’s look at a couple REAL scenarios with two companies in my ecosystem.
How much faster is it?
Company A: It has some prompts that go to an LLM with user input to do dynamic output.
Company B: It has some prompts that go to an LLM with data from the database to fill in other fields in the database.
Company A has the SME write the prompt. The SME then sends the prompt to the dev team to deploy. The dev team then includes it in the next release.
Initial Engineering Time: 4 hours per prompt.
Engineering Effort per Prompt Version: 15 minutes.
Prompt turn-around time: 2 business days.
Company B had the dev team build a prompt management infrastructure. It included logging, wiring in fields from the database for input and mapping for output, versioning, cost management/visibility, and more.
Initial engineering time: 40 hours.
Engineering Effort per Prompt: 0 hours.
Minimum turn around time after the prompt is written: 0 hours.
Company B’s approach is not very MVPy. It took longer to get the initial solution deployed. But, the product velocity is incredibly higher in the organization that took the time to have the dev team build the infrastructure for the SMEs. Turns out Company A then needed to wire in more prompts over time. The product team now has to deal with managing the change process for multiple prompts which each took time to wire in, configure, manage, & deploy.
BUT EVEN MORE INTERESTING
Company A’s team was less likely to ad hoc test new prompts.
Company B’s team used exponentially more prompts over time.
I posit this would be true for:
- rules that are codified vs deployed with a rule engine
- reports that are coded vs built with a report builder
- workflows that are hand managed vs built in a workflow builder
- and the list goes on…
Enterprise Software is thus exponentially more valuable than normal software because of SMEs ability to adapt it
If each area that a SME can touch will undergo this type of utilization explosion when unhampered by engineering… should the engineering & product teams’ responsibility not be to build tools for the SMEs?
The good news is there are tools out there to help you adopt the enterprise approach. One should consider:
Open Source & Paid Solutions That Bring Enterprise Solutions to SMBs & Smaller Teams
I’ve recently dealt with similar scenarios with rules engines, content management, & even reports.
If your company is hand-coding reports you’re probably are going to regret it.