On 29 September the class took a bus to Lolland to visit Engestofte Gods, the company behind the market case. We got a tour of the estate, and the teams showed their prototypes to the people the projects were built for.
The Place#
My project started as a transcript and a conversation, so it was nice to see the real thing. The estate was a lot like I’d pictured: an old estate with multiple buildings. I’d also looked at pictures beforehand for the app. The biggest building was less renovated than I expected, while the venue where they hold weddings was a big, beautiful room with a view of the lake.
I wouldn’t call anything about the visit a surprise, and I think that’s a good result in itself. My picture of the case turned out to be accurate, which is what you want before building on it. The wedding venue also made it easy to see why I chose the market over weddings: that’s where the personal touch matters.
We also heard a little from students on the Innovation and Entrepreneurship line, who had been given the job of finding opportunities for the company. That’s a different story from mine, so I’ll leave it there.
The Demo#
Lise, who runs the market, and Johan, who plans the weddings and gave the interview our transcript came from, both saw our demo. From my understanding they were quite excited about it, and about the other teams’ solutions to their own cases. I was thoroughly impressed by what was shown. The other teams worked in different domains than mine, so there wasn’t much to borrow directly, but it was good to see what the approach can do on real cases.
I kept the demo non-technical, and I’d call what we showed a beautiful shell: a design with placeholders and the general features, plus a couple of basics that actually worked, like making an application and assigning a stallholder a place. I told them it was a concept of a finished design, so I don’t feel I misled anyone.
Showing a shell was a deliberate choice. The idea came out of a transcript and a conversation where the company hadn’t said exactly what they wanted. In that situation a demo works more like a question than a proof. What I wanted to know was which features got a reaction, and which were more nice than need to have, and a polished design with placeholders gets you that answer faster than a tested but ugly build.
The One Question#
The only thing the company really asked about, confirmed where the biggest pain point is. Lise asked whether the reminder email could come with the application data prefilled, because that’s the biggest hurdle she has with returning stallholders.
That became an important feature, and we’ve already implemented it. The prefilled form opens through a long, random magic link that can expire, so it works without a login. Prefilling does mean keeping last year’s applications, so for how long and why is something I still need to think through.
When it’s the only thing they mention, it’s obvious that it matters. I’ll admit I also read something into what they didn’t say. They aren’t tech-savvy, and I suspect their picture of what’s possible is limited, since it’s hard to ask for features you can’t picture. But they also didn’t have long, so “no other feedback” may just mean “no other objections yet”.
What Changes#
Most of my assumptions held, so the priority became the feature they asked for, and making sure everything else I showed is refined and tightened. A shell that looks finished points at things you’ve implicitly promised, so the rest of the project is about closing the gap between what the demo suggested and what exists. I don’t want to leave any empty promises behind.
Wrap Up#
Sometimes a pretty shell is enough to get an idea across.