business

Verdict

Submitted 5/28/2026, 7:12:35 AM · Completed 5/28/2026, 7:14:59 AM

5.5
pivot
The idea

End to end no touch autopilot install via MDT with user driven profiles and remote rebuilding

Pain point
Legacy MDT systems cannot support self-deploy on Lenovo devices with FTPM instead of TPM chips.
Who has this problem
IT administrators managing Lenovo devices with MDT
Contradiction (TRIZ)
Need for self-deploy functionality vs. hardware limitations of FTPM chips
Ideal final result
Self-deploy functionality that works seamlessly with FTPM-based Lenovo devices
Suggested solution
Implement a custom MDT task sequence with user-driven profiles and remote rebuilding capabilities, using FTPM-compatible authentication methods and PXE boot for automated deployment.
Show original source text →
Hi all, Just wanted to share a cool win I had today. Bit of background - we still use MDT, yes I know it’s legacy but it works for us! We’ve spent ages trying to get self deploy working via autopilot but all our devices are Lenovo devices and use FTPM instead of TPM chips so self deploy will not work for love nor money. I’ve managed to get MDT to autofill the username and password of a user driven deployment so it runs through automatically, as part of this work I’ve also managed to push an agent as part of the MDT task sequence that enables remote rebuilding in MDT like SCCM offers, so we can now push a rebuild from a central console and the machine will reboot into PXE and build end to end with a finished autopilot/intune joined device. We have several task sequences to assign different group tags and the console allows us to select the TS we want to push, the machine then launches winPE and auto runs that TS. I’ve added renaming into the tool also so we can set the device name remotely once it’s built. Now we have end to end ‘self driven’ deployments using user driven profiles and MDT. Just wanted to share! :)
TRIZ inventive level: 3/5· Principles: parameter changes, self-service
Synthesis verdict
**Pivot**: The idea has a unique value proposition, but its viability and market potential are limited due to technical complexity and niche appeal. The solution addresses a specific pain point for organizations using MDT with Lenovo devices, but its reliance on legacy technology and custom workarounds reduces its scalability and competitiveness. To improve, the solution could be reframed to focus on more modern and widely adopted technologies, such as Intune and cloud-based management tools.

Strengths

  • Unique value proposition addressing a specific pain point for MDT users with Lenovo devices
  • High-margin, niche solution with strong conversion potential among IT admins
  • Custom MDT-based console provides genuine differentiation from existing SCCM/Ivanti/ManageEngine offerings

Weaknesses

  • Technical complexity and specificity of the solution make it challenging to replicate and maintain
  • Niche appeal due to legacy tech and specific hardware requirements severely limits market potential and scalability
  • Dependence on outdated technology positions the venture against the trend of modern, cloud-based management tools

Best angle

Reframe the solution to focus on more modern and widely adopted technologies, such as Intune and cloud-based management tools, to increase scalability and competitiveness.

Panel verdicts

Competition

nvidia/nemotron-3-nano-omni-30b-a3b-reasoning

8.0

A custom MDT‑based console that handles FTPM Lenovo devices and remote rebuilds provides a genuine, durable differentiation from existing SCCM/Ivanti/ManageEngine offerings.

The market already offers OS deployment solutions such as Microsoft Endpoint Configuration Manager (SCCM) with MDT, Ivanti Deployment Manager, and ManageEngine Desktop Central, all of which can perform automated imaging and OS deployment over PXE. However, none of these provide a built‑in, user‑driven console that specifically addresses the FTPM limitation on Lenovo devices and automates remote rebuilds with a single click. The entrant's solution layers a custom management UI on top of MDT, adds a remote‑agent step for rebuild, and handles device naming, thereby filling a niche that Autopilot cannot satisfy. Because the approach leverages existing, supported Windows tooling (MDT, PXE, Intune) while adding a focused, differentiated workflow, the differentiation is both real and likely durable, though it depends on continued maintenance of the custom console. This justifies a score above the midpoint but not a perfect 10, as the value is niche and could be replicated if competitors extend their tools to support FTPM devices.

Risk

nvidia/llama-3.3-nemotron-super-49b-v1

2.0

Niche appeal due to legacy tech and specific hardware requirements severely limits market potential and scalability.

The proposed business venture relies on a heavily customized, legacy system (MDT) with non-standard hardware (FTPM instead of TPM), limiting scalability and appeal to a broader market. The solution's value proposition is highly niche, catering only to organizations with identical or very similar infrastructure challenges, drastically reducing potential customer base. Furthermore, the dependence on outdated technology positions the venture against the trend of modern, cloud-based management tools (e.g., Intune, SCCM), making it less competitive in terms of future-proofing and integration capabilities. Regulatory or platform updates could quickly obsolete this workaround.

Viability

meta/llama-4-maverick-17b-128e-instruct

2.0

The technical complexity and specificity of the solution to the existing infrastructure and device limitations make it challenging for a small team to replicate within a short timeframe.

The described solution heavily relies on customizing and integrating MDT (Microsoft Deployment Toolkit) with existing infrastructure, including Autopilot and Intune, for automating device deployments. The complexity arises from working around limitations due to Lenovo devices using FTPM instead of TPM chips, and integrating a custom agent for remote rebuilding. While the technical details provided suggest a deep understanding of MDT and its potential for automation, replicating this as a business venture by a solo or 2-person team within 4-12 weeks is highly challenging. The solution involves intricate knowledge of MDT task sequences, Autopilot, Intune, and custom agent development. Moreover, the workaround for FTPM vs TPM and the development of a remote rebuilding agent indicate a high level of technical complexity. The team would need extensive experience with MDT, Windows deployment, and potentially developing or heavily customizing software agents. Given these complexities and the need to potentially support various Lenovo devices and configurations, the feasibility is low for a small team to develop a viable v1 within the given timeframe.

Monetization

mistralai/mistral-nemotron(fallback #1)

7.0

This tool fills a critical gap for MDT users with Lenovo devices, offering a high-margin, niche solution with strong conversion potential among IT admins.

This solution addresses a niche but significant pain point for organizations still using MDT (Microsoft Deployment Toolkit) with Lenovo devices that lack TPM chips, preventing Autopilot self-deployment. The monetization potential lies in packaging this as a premium add-on for MDT or a standalone tool. Pricing could be tiered: a one-time license fee ($500-$1,000 per organization) for the console and agent, with optional annual support/subscription ($200-$500). Conversion would target IT admins via direct outreach, webinars, and partnerships with Lenovo or MDT communities. Gross margins could be high (80%+) given the digital nature of the product, with low cost-to-serve (automated updates, minimal support). The key challenge is the shrinking MDT user base, but the solution’s uniqueness and time-saving benefits justify the score.

Market

moonshotai/kimi-k2.6(fallback #1)

5.0

The author appears to have achieved a technical win by chaining Microsoft Deployment Toolkit (MDT) or Configuration Manager (SCCM) task sequences with Windows Autopilot and remote management tools, but the message is so poorly constructed that the specific innovation or value proposition is lost.

The text is a highly garbled, stream-of-consciousness dump mixing technical jargon (MDT, SCCM, TS, WinPE, PXE, Intune, Autopilot), personal anecdotes ('wanted to share a cool win'), and fragmented sentences. It appears to describe an IT deployment/automation scenario but is nearly incomprehensible due to extreme typos, autocorrect artifacts, missing punctuation, and logical jumps. While a patient reader might infer the author successfully automated device imaging/reimaging remotely, the writing quality is exceptionally poor. It fails basic standards of clarity, grammar, and coherence. It is not suitable for professional communication, though the underlying technical concept might have merit if rewritten.

Synthesized by meta/llama-3.3-70b-instruct · 12.2s