Published on

Proof of Concepts, what are they and how do they apply to knowledge management?


Proof of Concept (POC) is a common term in the technology space, but what about it when the focus is knowledge management? Turns out that the same term has small, but very important differences.


A Proof of Concept from the technological view point (POC) aims at questioning the feasibility of an idea and at testing its fundamental technical elements, in order to identify and reduce the risks that might arise during the actual development. In most cases, it’s an internal project, but sometimes can be used for showcasing your idea to investors1. The focus is on technical aspects such as system integration, performance, scalability, security, and usability2.

On the other hand, from a knowledge management perspective, a POC serves as an experimental approach for testing new ideas or concepts within an organization’s knowledge ecosystem. It focuses on knowledge creation, sharing, utilization, and retention rather than solely on technological capabilities. The emphasis is on exploring how the proposed solution can enhance collaboration among employees or improve organizational learning processes. This makes a POC (KM-POC) a requirements analysis tool.

Proof of Concept (POC) is a valuable tool used to test the feasibility and functionality of technology or new ideas. From a tech perspective, it validates if the proposed solution meets user requirements. In knowledge management, POCs focus on enhancing collaboration and organizational learning processes. Both approaches have different objectives, stakeholders, evaluation criteria, and success metrics.

Key differences between these two perspectives include:

  • Objectives. Technology-focused POCs aim to assess technical feasibility and to confirm that a specific technology stack is able to fulfill the functional and non-functional requirements. Knowledge management-focused POCs seek to evaluate how well new ideas or concepts align with organizational goals in terms of enhancing knowledge flows and improving decision-making processes.
  • Stakeholders. In technology-focused POCs, stakeholders typically include IT professionals who are responsible for implementing and maintaining technologies within an organization. In contrast, knowledge management-focused POCs involve various stakeholders such as subject matter experts (SMEs), managers from different departments/divisions/teams involved in generating or utilizing knowledge assets.
  • Evaluation Criteria. Technology-focused POCs primarily focus on evaluating technical factors such as system performance metrics (e.g., response time), compatibility with existing infrastructure/processes/security concerns while ensuring compliance with standards/regulations if applicable. Knowledge management-focused POCs emphasize assessing how well new ideas/concepts integrate into existing workflows/processes/knowledge repositories, resulting in improved collaboration/learning outcomes.
  • Success Metrics. For technology-centric POCs success may be measured based on technical benchmarks achieved during testing/validation phases (e.g., successful completion of stress/load tests). In contrast, knowledge management-focused POCs may focus on metrics such as increased knowledge sharing/collaboration, improved decision-making, or enhanced organizational learning.

Overall, while both perspectives involve POCs to test new ideas/concepts, the emphasis and evaluation criteria differ significantly. Technology-focused POCs concentrate on technical feasibility and functionality, whereas knowledge management-focused POCs emphasize enhancing organizational knowledge processes and outcomes.

What comes after a POC?

The Proof of Concept is usually the first of a multi-stage approach. This is valid from both technology and Knowledge management perspectives.

The diagram compares the phases after both technological and knowledge POC with respect to the time required.
Phases after the POC with respect to required time.

Considering the time and effort the technological-POC is followed by (1) a minimal viable product 3 and then (2) the product.

A Knowlegde-POC instead is followed by three phases:

  1. Pilot. The POC is scaled in terms of involved resources and use cases.
  2. Roll-out. All expected users are involved and internal processes tuned.
  3. Institutionalisation. The knowledge management system is part of the organisational culture.

For an in-depth look at each phase see the KM-F Implementation journey (section 3).

Which POC to use?

The ultimate goal of a POC is to study the feasibility of adopting a disrupting technical or organizational solution. At OneOff-Tech we don’t look at technical-POC or Knowledge-POC, but at an interconnected approach whose ultimate goal is the balance of people, processes, technologies and governance (i.e. the four legs). A successful implementation requires a holistic approach that combines/bridges both, technological and knoweldge, POC under a common goal-driven methodology.

  1. Proof of Concept (POC): Definition And Why Is Important For Your Company (last accessed 2023-08-29) ↩︎

  2. For an in-depth look check POC vs Prototype vs MVP: What's the difference? (last accessed 2023-08-29) ↩︎

  3. Minimal Viable Products can be followed by Minimal Marketable Products or, in general, more iterations before reaching what can be identified as the product status. Read more on Minimum Viable Product vs Minimum Marketable Product (last accessed 2023-08-29) ↩︎