Define-ML: An Approach to Ideate Machine Learning-Enabled Systems

Antonio Pedro Santos Alves; H\'elio Lopes; Lucas Romao; Marcos Kalinowski; Silvio Alonso

REVIEW 4 major objections 5 minor 19 references

Define-ML: An Approach to Ideate Machine Learning-Enabled Systems

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that Define-ML, a Lean Inception extension, overcomes traditional ideation methods' blind spots for ML systems by making data sources and ML feasibility explicit, and reports unanimous intention to adopt it among…

desk verdict A clearly written method paper with a genuinely new integration of existing ideation tools, but the evidence is perceptual and the 'validated' wording oversells it; still worth a serious peer review. read the letter →

arxiv 2506.20621 v1 pith:MVPAZPTJ submitted 2025-06-25 cs.SE cs.AI

Silvio Alonso , Antonio Pedro Santos Alves , Lucas Romao , Hélio Lopes , Marcos Kalinowski This is my paper · ORCID

classification cs.SEcs.AI

keywords Define-MLML-enabledsystemsideationLeanInceptiondatamappingmachinelearningproductdiscoverytechnologyacceptance

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Define-ML is a workshop framework that extends the Lean Inception ideation method with three activities built around data and machine-learning feasibility: Data Source Mapping, Feature-to-Data Source Mapping, and ML Mapping. The authors' central claim is that these activities close a gap in traditional ideation methods, which lack explicit support for data dependencies and probabilistic behavior when conceiving ML-enabled systems. They validate the framework with a toy-problem session among industry practitioners and a real-world workshop on retail demand forecasting for an energy drink company. Participants reported that the activities clarified data constraints, aligned ML capabilities with business goals, and improved cross-functional collaboration, and every questionnaire respondent indicated intention to adopt the approach. The paper positions Define-ML as an openly released, validated approach for grounding ML product ideas in what data and models can actually support.

What carries the argument

The central mechanism is the three-activity sequence, each supported by a visual board. Data Source Mapping positions data sources on axes of public versus private and corporate governance, with quality circles for high, medium, and low quality. Feature-to-Data Source Mapping links each prioritized feature to the data sources needed to build it, exposing the MVP's data dependencies. ML Mapping separates ML-intensive from non-ML features, attaches each ML-intensive feature to a business objective, then uses tokens for data types and ML capabilities to match data sources to plausible model types. These activities are carried out during a collaborative workshop that includes ML experts, who provide real-time feasibility judgments that keep ideas grounded in what is technically achievable.

What would settle it

A concrete test would be a controlled longitudinal comparison where teams ideate ML-enabled products using either Define-ML or the unmodified Lean Inception, with facilitation kept neutral, and success measured by objective outcomes such as the share of ideated features that reach a deployed product using available data, the rate of feature pivots due to data unavailability, or stakeholder alignment scores over time. If Define-ML teams show no fewer data-related dead ends and no better alignment than the Lean Inception baseline, the central claim would be refuted.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that a structured extension of Lean Inception—adding Data Source Mapping, Feature-to-Data Source Mapping, and ML Mapping—can address the distinct challenges of ideating ML-enabled systems, namely aligning business objectives with probabilistic behavior and making data dependencies explicit early. The three activities ask teams to map data sources by access and governance, connect each proposed feature to the data it needs, and match ML-intensive features to feasible model types while tying each to a business objective. Static validation with a simulated loan-approval problem and dynamic validation in a retail demand-forecasting case both yielded high perceived usefulness on the new activities and unanimous expressed intention to adopt the framework. The authors conclude that Define-ML provides a structured framework for addressing the unique challenges of ideating ML-enabled systems.

Load-bearing premise

The load-bearing premise is that participants' questionnaire answers about perceived usefulness, ease of use, and intention to adopt—collected right after researcher-facilitated workshops—are a reliable stand-in for the framework's true effectiveness in real product ideation.

Editorial extensions

If this is right

If Define-ML works as reported, teams can surface data gaps and feasibility constraints before committing to an ML product vision, reducing later rework.
The feature-to-data matrix gives the MVP definition an explicit data-dependency input, making scope decisions more realistic.
The structured activities give business and technical stakeholders a shared vocabulary, fostering cross-functional alignment on data-driven products.
The open template release means practitioners can adopt the framework without proprietary tools, and the documented facilitation role suggests organizations should budget for ML-expert support.
Acceptance across two industry contexts (energy sector and retail/beverage) offers initial evidence of applicability beyond a single domain.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Editorial inference: the same data-to-feature mapping logic could extend beyond ML to any data-intensive product ideation, since data dependency is not unique to predictive features.
Editorial inference: because all workshops were researcher-facilitated and evaluation was self-reported, the unanimous adoption intent may overstate what would happen when teams run Define-ML on their own; a replication with neutral facilitation would test the persistence of the effect.
Editorial inference: the ML Mapping step, built on data-type and capability tokens, could be extended to generative AI and agent-based features (as the authors suggest as future work) by adding tokens for those capability classes.
Editorial inference: the artifacts Define-ML produces, such as the feature-to-data-source matrix, could feed directly into requirements engineering for ML, potentially reducing the specification gap documented in prior work.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The thing to know: Define-ML is a new combination of Lean Inception and the Mix & Match ML toolkit, with two additional mapping activities that force teams to think about data sources and data-to-feature dependencies early. That integration is not in the cited literature, and the paper gives you enough detail to run the workshop yourself. The Miro template and Zenodo data are a nice touch; this is reproducible enough for a methods paper.

What the paper does well: it is honest in the places that matter. The threats-to-validity section openly concedes that TAM captures perceptions and that facilitator bias is possible. The static and dynamic validations are described concretely, with participant quotes that give a real sense of what worked and what confused people. The learning curve for ML Mapping, the request for more time on Feature-to-Data Source Mapping, the one participant who found the artifact confusing—none of that is hidden. For an early-stage method proposal, this is solid qualitative groundwork.

The soft spot is the one the reader and stress-test both flagged: the jump from "participants said they liked it and intend to use it" to "validated approach" in the abstract and conclusion. There is no baseline, no objective measure of ideation quality, tiny samples (11 and 9), and the dynamic case lost two of eleven respondents. Unanimous intention to adopt is a behavioral intention measured at the end of a facilitated workshop, not adoption. The authors themselves write that the evidence is perceptual, so the overstatement is mainly in the abstract and conclusion, but it is still an overstatement. This is not a fatal flaw for a software engineering methods paper—TAM-based initial evaluation is common and acceptable when clearly labeled as preliminary—but the claims should be tempered.

Who this is for: researchers working on ML requirements and ideation, and practitioners who want a structured workshop format. It is a modest but useful step beyond existing toolkits because it embeds ML awareness into a full product-ideation flow. I would not cite it as evidence that Define-ML works; I would cite it as an example of a structured ideation method with initial acceptance data.

My recommendation: send it to peer review. The method is clearly described, the evaluation is appropriately scoped if you read the caveats, and the limitations are acknowledged rather than buried. A serious referee should ask the authors to soften "validated" to something like "perceived as useful in initial evaluations," and to add a sentence in the conclusion that longitudinal and comparative studies are still needed. That is a revision, not a rejection.

Referee Report

4 major / 5 minor

Summary. The paper proposes Define-ML, an extension of the Lean Inception ideation workshop with three new activities (Data Source Mapping, Feature-to-Data Source Mapping, and ML Mapping) intended to address ML-specific concerns in early product ideation. The authors followed the Technology Transfer Model, first presenting the approach in a lab session, then running a static validation with 11 practitioners on a toy problem, and a dynamic validation in a three-day workshop with a multinational energy drink company, where 9 of 11 business participants completed a TAM-based questionnaire. The reported results show high perceived usefulness for the new activities and unanimous (static) or near-unanimous (dynamic) intention to adopt the framework. The paper concludes that Define-ML is a 'validated approach' for ML product ideation. The manuscript includes an open science repository and a Miro template for the boards.

Significance. If the results are taken at face value, Define-ML addresses a real and current gap: most ideation methods for software products do not explicitly handle data dependencies, technical feasibility, and the alignment of ML capabilities with business goals. The paper's strengths are its concrete, reproducible artifacts (open Miro template, Zenodo repository), its adherence to a systematic technology-transfer methodology with defined research questions, and its candid threats-to-validity section, which explicitly acknowledges that TAM captures perceptions and that facilitator bias is possible. The evaluation, however, rests entirely on self-reported perceptions and behavioral intentions, with no baseline comparison, no objective outcome measures, small samples, and researcher-facilitated sessions. The paper would be a useful contribution as a design study reporting practitioner perceptions of a new ideation framework; the current wording overstates the strength of the evidence.

major comments (4)

[Abstract; Section VIII] The conclusion that Define-ML is a 'validated approach' for ML product ideation is not supported by the evidence presented. The evaluation in Sections V and VI uses TAM-based questionnaires that measure perceived usefulness, ease of use, and intention to use (Section VI.C), and the authors themselves concede in Section VII.B that 'TAM and qualitative feedback basically capture perceptions.' There is no objective measure of ideation outcome quality, such as feasibility of the produced product definition, alignment with available data, or downstream project success. I recommend either tempering the claim to 'an approach that practitioners perceived as useful' or adding evidence that links the workshop outputs to actual ideation effectiveness.
[Sections V and VI] Neither validation includes a comparison baseline. All participants used only Define-ML, so the high agreement ratings could reflect the general value of any structured, facilitated workshop rather than the specific contribution of the three ML-focused activities. To support the central claim that these activities add value over and above Lean Inception, a comparison with an unmodified Lean Inception session, or at least an explicit within-workshop evaluation of what each activity contributed beyond the baseline method, would be needed. Without such a comparison, the paper's motivation that traditional ideation methods 'lack explicit support for ML-specific considerations' (Section II.A) is plausible but not empirically backed by the reported data.
[Section VI.D, RQ3; Section V.D, RQ3] The characterization 'strong perceived usefulness' in the conclusion is too strong for the ML Mapping activity in the dynamic validation, where only 6 of 9 practitioners agreed, 2 partially agreed, and 1 was neutral, and where one participant reported that the artifact 'confused me most.' The static validation also had 2 of 11 participants only partially agreeing. The paper should either report this activity as only moderately supported or explain why these results still justify the overall claim of strong usefulness.
[Section VI.D, RQ4; Section VII.B] The 'intention to adopt' measure was collected immediately after the workshop and is a behavioral intention, not actual adoption. The authors correctly note in Section VII.B that longitudinal tracking is future work, but the conclusion in Section VIII states a 'clear practitioners' intent to adopt' as if it were evidence of adoption readiness. I recommend distinguishing clearly between reported intention and evidenced adoption in the abstract and conclusion, and noting the self-selection issue: only 9 of the 11 business participants answered the questionnaire, and the non-respondents may differ systematically from respondents.

minor comments (5)

[Abstract] The phrase 'intent of adoption' should be 'intention to adopt' to match the terminology used in Section VI.C and the TAM literature.
[Section VII.A] Typo: 'aproach' should be 'approach'.
[Sections V and VI] The manuscript frequently has stray spaces before periods in headings and section references (e.g., 'V . Yildirim' in Section II.B, 'F . Step 6' in Section III.F). Please fix these formatting issues in the final version.
[Section IV.A] The term 'corporate governance' in the Data Source Mapping board may be unclear to readers outside the specific organizational context; consider defining it explicitly or using a more self-explanatory label such as 'IT-managed data' vs. 'locally managed data'.
[Figures 5 and 7] Please ensure that the frequency bars are accompanied by the exact counts or percentages, since the numbers are central to the reader's ability to assess the strength of the agreement findings.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the validation evidence is empirical and self-reported, but the conclusions are not equivalent to the inputs by construction.

full rationale

This paper does not contain a mathematical derivation chain or fitted parameters, so the classic circularity failure modes do not apply. Define-ML is presented as an extension of Lean Inception with three new activities, and its evaluation is based on two empirical studies using TAM-based questionnaires and qualitative feedback. The conclusion that Define-ML is a 'validated approach' rests on participants' perceived usefulness, ease of use, and intention to adopt; this is an inferential limitation, not a circularity. The authors explicitly acknowledge in Section VII.B that 'TAM and qualitative feedback basically capture perceptions' and that 'all workshops were facilitated by the researchers, which could introduce facilitator bias.' These are honest threats to validity, and the paper does not disguise them. There is no step in which a quantity is defined in terms of the result it is supposed to predict, and no load-bearing self-citation chain: the cited prior work by the authors is used as background or motivation, not as an unverified uniqueness theorem that forces the conclusion. The central claim is therefore independent of its evidence in the sense required for circularity; the weakness is a standard external-validity and measurement concern, not a circular derivation.

Assumptions & free parameters 0 free parameters · 2 assumptions · 0 invented entities

No free parameters appear because the paper does not fit any model to data. The main assumptions are that self-reported perceptions capture real utility, and that Lean Inception truly has a gap for ML. No new physical or conceptual entities are introduced beyond the framework itself.

assumptions (2)

domain assumption Perceived usefulness measured by TAM questionnaires is a valid indicator of an ideation framework's practical value.
The entire validation rests on self-reported perceptions from participants. The authors themselves note in Section VII.B that TAM 'basically captures perceptions', which limits the strength of the conclusions.
domain assumption The Lean Inception method lacks sufficient support for ML-specific concerns such as data dependencies and feasibility.
This premise motivates the entire approach. It is supported by citations to prior work [1][3][14], but is not empirically tested within this paper.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Define-ML: An Approach to Ideate Machine Learning-Enabled Systems." pith.science (2026). https://pith.science/paper/MVPAZPTJ

@misc{pith2026250620621,
  author       = {Pith},
  title        = {Pith review of: Define-ML: An Approach to Ideate Machine Learning-Enabled Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MVPAZPTJ}},
  note         = {Machine review of arXiv:2506.20621}
}

read the original abstract

[Context] The increasing adoption of machine learning (ML) in software systems demands specialized ideation approaches that address ML-specific challenges, including data dependencies, technical feasibility, and alignment between business objectives and probabilistic system behavior. Traditional ideation methods like Lean Inception lack structured support for these ML considerations, which can result in misaligned product visions and unrealistic expectations. [Goal] This paper presents Define-ML, a framework that extends Lean Inception with tailored activities - Data Source Mapping, Feature-to-Data Source Mapping, and ML Mapping - to systematically integrate data and technical constraints into early-stage ML product ideation. [Method] We developed and validated Define-ML following the Technology Transfer Model, conducting both static validation (with a toy problem) and dynamic validation (in a real-world industrial case study). The analysis combined quantitative surveys with qualitative feedback, assessing utility, ease of use, and intent of adoption. [Results] Participants found Define-ML effective for clarifying data concerns, aligning ML capabilities with business goals, and fostering cross-functional collaboration. The approach's structured activities reduced ideation ambiguity, though some noted a learning curve for ML-specific components, which can be mitigated by expert facilitation. All participants expressed the intention to adopt Define-ML. [Conclusion] Define-ML provides an openly available, validated approach for ML product ideation, building on Lean Inception's agility while aligning features with available data and increasing awareness of technical feasibility.

Figures

Figures reproduced from arXiv: 2506.20621 by the authors.

**Figure 2.** Recognizing that ML products require specialized [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 4.** Feature-to-Data Source Mapping and ML Mapping [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗

Figures from the paper (3 more)

**Figure 3.** Figure 3: Data source mapping board The board is structured with two axes. The x-axis differentiates whether the data is public or private, helping the team quickly identify access restrictions and privacy considerations. The y-axis distinguishes whether the data is under corp…

**Figure 5.** Figure 5: Agreement frequencies on usefulness 1) RQ1: Data Source Mapping Perceived Usefulness: The majority of respondents (10 out of 11) agreed that the activity of mapping data sources is valuable for delineating ML-enabled system products. One participant partially agreed, i…

**Figure 7.** Figure 7: Frequencies of the responses 1) RQ1: Data Source Mapping Activity: Quantitative analysis revealed that 8 out of 9 participants (89%) agreed on the usefulness of the Data Source Mapping activity, with one participant expressing partial agreement. The themes that emerged…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

19 extracted references · 19 canonical work pages

[1]

A meta- summary of challenges in building products with ml components– collecting experiences from 4758+ practitioners,

N. Nahar, H. Zhang, G. Lewis, S. Zhou, and C. K ¨astner, “A meta- summary of challenges in building products with ml components– collecting experiences from 4758+ practitioners,” in2023 IEEE/ACM 2nd International Conference on AI Engineering–Software Engineering for AI (CAIN). IEEE, 2023, pp. 171–183

work page 2023
[2]

Lean inception: how to align people and build the right product,

P. Caroli, “Lean inception: how to align people and build the right product,”Editora Caroli, 2018

work page 2018
[3]

Status quo and problems of requirements engineering for machine learning: Results from an international survey,

A. P. S. Alves, M. Kalinowski, G. Giray, D. Mendez, N. Lavesson, K. Azevedo, H. Villamizar, T. Escovedo, H. Lopes, S. Bifflet al., “Status quo and problems of requirements engineering for machine learning: Results from an international survey,” inInternational Conference on Product-Focused Software Process Improvement, 2023, pp. 159–174

work page 2023
[4]

Naming the Pain in Machine Learning-Enabled Systems Engineering

M. Kalinowski, D. Mendez, G. Giray, A. P. S. Alves, K. Azevedo, T. Escovedo, H. Villamizar, H. Lopes, T. Baldassarre, S. Wagneret al., “Naming the pain in machine learning-enabled systems engineering,” arXiv preprint arXiv:2406.04359, 2024

work page Pith review arXiv 2024
[5]

A model for technology transfer in practice,

T. Gorschek, P. Garre, S. Larsson, and C. Wohlin, “A model for technology transfer in practice,”IEEE software, vol. 23, no. 6, pp. 88– 95, 2006

work page 2006
[6]

Design thinking,

T. Brownet al., “Design thinking,”Harvard business review, vol. 86, no. 6, p. 84, 2008

work page 2008
[7]

Banfield, C

R. Banfield, C. T. Lombardo, and T. Wax,Design sprint: A practical guidebook for building great digital products. ” O’Reilly”, 2015

work page 2015
[8]

Ries,The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses

E. Ries,The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. Crown Currency, 2011

work page 2011

Show all 19 references

[9]

Mix & match machine learning: An ideation toolkit to design machine learning-enabled solutions,

A. Jansen and S. Colombo, “Mix & match machine learning: An ideation toolkit to design machine learning-enabled solutions,” inProceedings of the Seventeenth International Conference on Tangible, Embedded, and Embodied Interaction, 2023, pp. 1–18

2023
[10]

Creating design resources to scaffold the ideation of ai concepts,

N. Yildirim, C. Oh, D. Sayar, K. Brand, S. Challa, V . Turri, N. Crosby Walton, A. E. Wong, J. Forlizzi, J. McCannet al., “Creating design resources to scaffold the ideation of ai concepts,” inProceedings of the 2023 ACM Designing Interactive Systems Conference, 2023, pp. 2326–2346

2023
[11]

Investigating how practitioners use human-ai guidelines: A case study on the people+ ai guidebook,

N. Yildirim, M. Pushkarna, N. Goyal, M. Wattenberg, and F. Vi ´egas, “Investigating how practitioners use human-ai guidelines: A case study on the people+ ai guidebook,” inProceedings of the 2023 CHI Confer- ence on Human Factors in Computing Systems, 2023, pp. 1–13

2023
[12]

Identify- ing concerns when specifying machine learning-enabled systems: A perspective-based approach,

H. Villamizar, M. Kalinowski, H. Lopes, and D. Mendez, “Identify- ing concerns when specifying machine learning-enabled systems: A perspective-based approach,”Journal of Systems and Software, vol. 213, 2024

2024
[13]

A systematic mapping study and practitioner insights on the use of software engineering practices to develop mvps,

S. Alonso, M. Kalinowski, B. Ferreira, S. D. Barbosa, and H. Lopes, “A systematic mapping study and practitioner insights on the use of software engineering practices to develop mvps,”Information and Software Technology, vol. 156, p. 107144, 2023

2023
[14]

Lessons learned to improve the ux practices in agile projects involving data science and process automation,

B. Ferreira, S. Marques, M. Kalinowski, H. Lopes, and S. D. Barbosa, “Lessons learned to improve the ux practices in agile projects involving data science and process automation,”Information and Software Tech- nology, vol. 155, p. 107106, 2023

2023
[15]

Lean r&d: An agile research and development approach for digi- tal transformation,

M. Kalinowski, H. Lopes, A. F. Teixeira, G. da Silva Cardoso, A. Ku- ramoto, B. Itagyba, S. T. Batista, J. A. Pereira, T. Silva, J. A. Warrak et al., “Lean r&d: An agile research and development approach for digi- tal transformation,” inProduct-Focused Software Process Improve...

2020
[16]

Experiences applying lean r&d in industry-academia collaboration projects,

M. Kalinowski, L. Romao, A. Rodrigues, C. Barbosa, H. Villamizar, S. D. Barbosa, and H. Lopes, “Experiences applying lean r&d in industry-academia collaboration projects,” in17th International Confer- ence on Software Quality, Software Quality Days SWQD 2025, Munich, Germany, ...

2025
[17]

Runeson, M

P. Runeson, M. Host, A. Rainer, and B. Regnell,Case study research in software engineering: Guidelines and examples. John Wiley & Sons, 2012

2012
[18]

The tame project: Towards improvement-oriented software environments,

V . R. Basili and H. D. Rombach, “The tame project: Towards improvement-oriented software environments,”IEEE Transactions on software engineering, vol. 14, no. 6, pp. 758–773, 1988

1988
[19]

Perceived usefulness, perceived ease of use, and user acceptance of information technology,

F. D. Davis, “Perceived usefulness, perceived ease of use, and user acceptance of information technology,”MIS quarterly, pp. 319–340, 1989

1989

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.

[1] [1]

A meta- summary of challenges in building products with ml components– collecting experiences from 4758+ practitioners,

N. Nahar, H. Zhang, G. Lewis, S. Zhou, and C. K ¨astner, “A meta- summary of challenges in building products with ml components– collecting experiences from 4758+ practitioners,” in2023 IEEE/ACM 2nd International Conference on AI Engineering–Software Engineering for AI (CAIN). IEEE, 2023, pp. 171–183

work page 2023

[2] [2]

Lean inception: how to align people and build the right product,

P. Caroli, “Lean inception: how to align people and build the right product,”Editora Caroli, 2018

work page 2018

[3] [3]

Status quo and problems of requirements engineering for machine learning: Results from an international survey,

A. P. S. Alves, M. Kalinowski, G. Giray, D. Mendez, N. Lavesson, K. Azevedo, H. Villamizar, T. Escovedo, H. Lopes, S. Bifflet al., “Status quo and problems of requirements engineering for machine learning: Results from an international survey,” inInternational Conference on Product-Focused Software Process Improvement, 2023, pp. 159–174

work page 2023

[4] [4]

Naming the Pain in Machine Learning-Enabled Systems Engineering

M. Kalinowski, D. Mendez, G. Giray, A. P. S. Alves, K. Azevedo, T. Escovedo, H. Villamizar, H. Lopes, T. Baldassarre, S. Wagneret al., “Naming the pain in machine learning-enabled systems engineering,” arXiv preprint arXiv:2406.04359, 2024

work page Pith review arXiv 2024

[5] [5]

A model for technology transfer in practice,

T. Gorschek, P. Garre, S. Larsson, and C. Wohlin, “A model for technology transfer in practice,”IEEE software, vol. 23, no. 6, pp. 88– 95, 2006

work page 2006

[6] [6]

Design thinking,

T. Brownet al., “Design thinking,”Harvard business review, vol. 86, no. 6, p. 84, 2008

work page 2008

[7] [7]

Banfield, C

R. Banfield, C. T. Lombardo, and T. Wax,Design sprint: A practical guidebook for building great digital products. ” O’Reilly”, 2015

work page 2015

[8] [8]

Ries,The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses

E. Ries,The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. Crown Currency, 2011

work page 2011