5 papers indexed here
We haven’t gathered this author’s papers yet. Follow them and we’ll fetch their work.
Not the right person? Other researchers publish under this name.
A Simultaneous, Multidisciplinary Development and Design Journey - Reflections on Prototyping
This paper proposes a wayfaring approach for the early concept creation stage of development projects that have a very high degree of intended innovation and thus uncertainty. The method is supported by a concrete game design example involving the development of a tangible programming interface for virtual car racing games. We focus onto projects that not only have high degrees of freedom, for example in terms of reframing the problem or iterating the final project vision, but are also complex in nature. For example, these can be projects that allow for the exploration and exploitation of unknown unknowns and serendipity findings. Process wise we are primarily focusing onto the early stage that precedes the requirement fixation, which we see as more dynamic and evolutionary in nature. The core conceptual elements that we have derived from the development experiences are: simultaneous prototyping in multiple disciplines (such as computer science, electronics and mechanics and engineering in general, abductive learning based on the outcome of rapid cycles of designing, building and testing prototypes (probing), and the importance of includingall the involved disciplines (knowledge domains) from the beginning of the project on.
Bridging Tangible and Virtual Interaction: Rapid Prototyping of a Gaming Idea
The Fibo Car is an example for a game interface that allows a user to modify a virtual car in a racing game through assembling tangible car parts. This paper describes the 6 week development journey towards a fully functional proof of concept prototype, reflections on the process as well as the technical details of the prototype.
Towards Understanding Startup Product Development as Effectual Entrepreneurial Behaviors
Software startups face with multiple technical and business challenges, which could make the startup journey longer, or even become a failure. Little is known about entrepreneurial decision making as a direct force to startup development outcome. In this study, we attempted to apply a behaviour theory of entrepreneurial firms to understand the root-cause of some software startup s challenges. Six common challenges related to prototyping and product development in twenty software startups were identified. We found the behaviour theory as a useful theoretical lens to explain the technical challenges. Software startups search for local optimal solutions, emphasise on short-run feedback rather than long-run strategies, which results in vague prototype planning, paradox of demonstration and evolving throw-away prototypes. The finding implies that effectual entrepreneurial processes might require a more suitable product development approach than the current state-of-practice.
Building an entrepreneurship data warehouse
The main principle of the Lean Startup movement is that static business planning should be replaced by a dynamic development, where products, services, business model elements, business objectives and activities are frequently changed based on constant customer feedback. Our ambition is to empirically measure if such changes of the business idea, the business model elements, the project management and close interaction with customers really increases the success rate of entrepreneurs, and in what way. Our first paper; “Does Lean Startup really work? Foundation for an empirical study” presented the first attempt to model the relations we want to measure. This paper will focus on how to build and set up a test harness (from now on called the Entrepreneurship Platform or EP) to gather empirical data from Companies and how to store these data together with demographical and financial data from the PROFF-portal in the Entrepreneurial Data Warehouse (from now called the EDW). We will end the paper by discussing the potential methodological problems with our method, before we document a test run of our set-up to verify that we are actually able to populate the Data Warehouse with time series data.