From idea to a working product in two weeks
I thought it would take six months. Two weeks later, I was using the first working version.
Category:
Strategy & AI
Author:
Ana Andersen
Read:
8 min
Location:
Norway
Date:
With AI as part of the development process, I had built a career platform that brought opportunities, contacts, assessments and follow-ups into one place. Six months had been my own expectation, not a measured development estimate. Still, the difference was enough to change how I think about which ideas are realistic to pursue.
The most interesting part wasn’t the speed itself. It was how early I could discover weaknesses in my own ideas, test alternatives and change direction while the problem was still fresh.
Through Studio Organic and my work across several hotel brands, I’ve become used to finding direction in complex situations and following it through strategy, creative development and implementation. I also know how much distance there can be between a good idea and the opportunity to find out whether it works.
In this project, I could work through far more of the development myself. It made me think about all the needs organisations leave unexplored because we assume investigating them will require too much time, money or capacity.
How might our priorities change if we could test an idea before deciding where to invest further?
A real problem to build around
The starting point was my own process of evaluating career opportunities. Information was scattered across job portals, documents, messages and conversations. I kept spending time reconstructing earlier assessments, finding the latest document and remembering what needed following up.
But the problem wasn’t simply a lack of organisation.
A promising job title could hide a role with little of the strategic responsibility I was looking for. An opportunity might appear relevant on paper but require more investigation before I could decide whether it deserved my time.
I needed more than a place to store information. I needed something that would help me make better decisions and understand what to do next.
I started with a structured setup and gradually developed my own app. AI supported research, analysis, assessments and drafting, while the platform connected opportunities, people, evidence and follow-ups. I defined the problem, prioritised features, shaped the user experience and reviewed the results, with AI supporting the coding as well.
What is often called vibe coding allowed me to work directly with a functioning solution without having every detail resolved in advance.
It also meant my assumptions were tested much earlier.
Sketches of the platform’s structure, core user journey and shared data foundation.
The first decision: Don’t make the wrong things faster
I could use AI to find more roles and produce more application drafts. But that wouldn’t necessarily make the process better.
A solution designed only to increase output could simply make me more efficient at pursuing the wrong opportunities.
So I separated two assessments: How well does my experience fit this role? And how well does the role fit the direction I want to take?
Those questions can produce very different answers.
A position might make good use of my existing skills but offer little room for strategic ownership or growth. Another might have a less obvious title but a much more interesting mandate.
I built that distinction into the platform’s assessment criteria. Responsibilities, autonomy and opportunities for development became part of the decision, rather than relying on the match between a CV and a job description.
This was where my experience with positioning became useful in a different context. A strategic direction only matters if it changes what we choose to pursue.
It also raised a broader question: What assumptions are we building into our systems?
A solution can become extremely efficient at recommending something we should have stopped prioritising.
When the solution started recreating the problem
As the platform developed, it gained more features, statuses and document versions. The information was coming together, but I was spending time coordinating everything again.
I had built some of the original complexity back into the solution.
Deadlines were stored, but not visible where I needed them. Drafts waiting for revisions were difficult to find. The information existed, but working out the next action was still my responsibility.
That changed the direction of the user experience.
I worked towards a shared, up-to-date source of information and a simpler starting point: “My Day”. Instead of opening the app to everything it contained, I wanted to see what actually needed attention: what to review, decide or follow up.
I moved from organising the platform around the information it stored to organising it around the situation the user was in.
It also gave me a clearer test for new features. Did they help me move forward, or did they create one more thing to manage?
I recognise this challenge from working with customer experience and services. It’s relatively easy to make a system more comprehensive. Making it genuinely easier to use takes more thought.
Building became a way to investigate the problem
The process wasn’t neat or linear.
I moved between exploring the need, defining the problem, developing and testing. Sometimes a new feature improved the experience. Other times, using the platform revealed that I had misunderstood the problem itself.
The Design Council’s Double Diamond offers a useful way to understand the movement between defining the right problem and developing a solution. In practice, though, I kept moving back and forth between those activities.
Double Diamond diagram from Jason Carlin’s free Figma template via UIKit Free, based on the Design Council’s Double Diamond.
Hyper Island’s Learning Spiral describes another important part of the process: doing, reflecting, drawing out insight and applying it in the next attempt.
Illustration adapted from Hyper Island’s Learning Spiral.
For me, this became very practical.
When deadlines were stored but still difficult to find, I had to rethink what an overview should actually do. Making information available wasn’t enough. The platform needed to help me act on it.
AI shortened the distance between an idea and something I could test. My experience in strategy, design and UX helped me understand why something wasn’t working and what needed to change.
Experience gave me direction. Using the product challenged it and gave me new insight.
Being responsible isn’t the same as being in control
From the beginning, one boundary was clear: AI could research and suggest. I would assess, approve and send.
But I discovered that adding an approval step at the end wasn’t enough.
A convincing recommendation is difficult to evaluate if I can’t see what it is based on, or if earlier decisions and corrections have been lost along the way.
I noticed, for example, that corrections could disappear between work sessions and that documents sometimes departed from approved visual references. A general description of language, colours and style left too much room for interpretation.
This felt familiar from brand implementation. A creative direction doesn’t become valuable simply because it has been well articulated. It has to hold together through countless small decisions about language, hierarchy, expression and detail.
I had to become more precise about how verified experience, previous decisions, actual references and feedback carried through the work across AI assistants and sessions.
In Moral Crumple Zones, researcher Madeleine Clare Elish examines situations in which people are held responsible for automated systems over which they have limited control. Her research concerns other, far more serious contexts than my platform, but the distinction between responsibility and actual influence is relevant here too.
In a 1995 study, Mica Endsley and Esin Kiris examined challenges associated with people taking control after automation. The research concerns a different technology, but highlights the importance of maintaining situation awareness.
For me, the question became: What do I need to understand along the way to intervene before a suggestion becomes a decision?
That changed how I approached quality. Control can’t be something that happens only at the end. It has to be possible throughout the workflow.
What is automation actually worth?
It’s tempting to measure the value of AI by how quickly something can be produced.
But a draft produced in minutes saves less time if I need to repeat the research before I can trust it. And a new feature doesn’t necessarily create value if it requires more data entry, checking or maintenance than the work it removes.
So I started looking at the work surrounding automation, not just what had been automated.
One practical example was how often the system should check whether I needed to find new contacts. More frequent checks were technically possible, but didn’t bring equivalent value. I reduced the frequency.
The fact that something can be automated is not, in itself, a reason to do more of it.
This isn’t a new problem. In Ironies of Automation, published in 1983, Lisanne Bainbridge described how automation can create new challenges for the people left to manage the remaining work.
That perspective gives me a more demanding measure of value: What work is the user left with?
I haven’t yet measured the total time saved by using the platform. Review, corrections, maintenance and resource use all belong in that calculation.
Building faster is interesting. Creating a better way of working is the goal.
When other people need to understand what I’ve built
I use the platform myself. Interest from others has also led to user testing and a tailored version.
That introduces a different kind of challenge.
I know the history, decisions and logic behind the platform. Other people shouldn’t need to know all of that to use it.
I’m now exploring what is self-explanatory, where people need support and which needs we genuinely share.
This is no longer just about the product’s features. It’s also about how a new way of working becomes part of people’s routines.
A solution that works well for the person who developed it isn’t automatically intuitive or valuable to anyone else. It has to fit how people work, give them confidence and justify the effort required to learn it.
I’ve moved from testing whether I could build the solution to examining whether it can work without me sitting beside the user.
A different starting point for investing in ideas
The most valuable thing I’ve gained from this project isn’t simply a new way to produce more in less time.
It’s a different way to work with uncertainty.
I could bring business understanding, creative development, UX and technology into the same process. I could test the consequences of strategic decisions directly in the product, identify weaknesses earlier and change direction before investing more work in the same assumptions.
In an organisation, I would start by looking at tasks people repeatedly have to reconstruct, information they manually bring together, or decisions delayed because the context is difficult to access.
Then I would investigate whether a small, focused solution actually made the work better before committing further resources.
As building becomes more accessible, more possibilities become worth exploring. But that doesn’t make strategic choices less important. Quite the opposite.
The project has made me more ambitious about what I can help create. It has also given me stricter criteria for what deserves to be developed further.
When building becomes easier, deciding what deserves our time matters even more.
Research and references
Madeleine Clare Elish (2019): Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction.
Mica R. Endsley and Esin O. Kiris (1995): The Out-of-the-Loop Performance Problem and Level of Control in Automation.
Lisanne Bainbridge (1983): Ironies of Automation.
Design Council: The Double Diamond.
Hyper Island: Experiential Learning and the Learning Spiral.
