The SIH Mindset: How We Stopped Trying to Be the Best Team and Started Trying to Be Impossible to Ignore
Don’t Be the Best Team. Be the Team Nobody Can Ignore
A story-driven guide to problem selection, contrarian thinking, systems thinking, feasibility, product design, and presentation strategy for Smart India Hackathon.
Series: The SIH Journey
"You don’t always have to compete by being better than everyone else. Sometimes, you win by becoming something nobody else thought to become."
Build something good.
Make it work.
Present it well.
Hope the judges like it.
There is nothing wrong with that strategy. But SIH is not just a coding competition. It is a competition of problem selection, reasoning, execution, communication, and differentiation.
And that creates a much more interesting question:
What happens when you stop asking, “How do we make the best project?” and start asking, “How do we become the team nobody can ignore?”
That question changed the way our team approached SIH. This is not a guide about some magical hackathon formula. It is the story of the mental models we developed while going through our SIH journey and how you can use those same models to approach your own hackathon.
1. Before the Project, Build the Team
Our SIH journey did not begin with a problem statement. It began much earlier. One of my closest teammates, Team Member 1, and I had carried the same goal since our second year:
We wanted to win SIH.
Over time, I had built a small team with people I trusted and with whom I had already participated in and won several hackathons. Team Member 2 and Team Member 3 were already part of that journey. I brought in Team Member 4, one of the juniors I trusted. Team Member 3 brought Team Member 5, someone completely new to the rest of us.
Six people eventually became one team. We were also from different departments:
Without deliberately designing some elaborate team-building strategy, we had accidentally created something important:
A multidisciplinary team.
And that matters more than many beginners realize. A hackathon team should not simply be six people who can code. You need people who approach the same problem from different directions.
Someone naturally asks: “Can we build this?”
Someone else asks: “Should we build this?”
Another asks: “Will a user actually understand this?”
Another asks: “Can we demonstrate this convincingly?”
And someone needs to be constantly asking: “What are we missing?”
That last question is particularly important.
Mental Model #1: Cognitive Diversity
The goal is not to assemble six versions of yourself. The goal is to assemble people who think differently but can still work toward one objective.
How we applied it
Instead of assigning people random roles immediately, we allowed people to contribute according to their strengths, Technical implementation, Research, Data, UI/UX, Presentation, Problem analysis, Architecture. Then we connected those pieces into one system.
For your SIH team
Before selecting a problem statement, ask every teammate independently:
“What do you see here that I don't?”
If everyone gives almost the same answer, your team probably has too little diversity of thought.
2. Our First Contrarian Move: We Chose the Problem Other Teams Didn't Want
When the problem statements were released, our strategy was deliberately unusual. We looked for a problem statement that was:
- Hard to implement.
- Unattractive to other teams.
- Easy for people to ignore.
- Confusing enough that most teams wouldn't want to touch it.
Our logic was simple, If nobody wants the problem, we want it. This was our first major mental model.
Mental Model #2: Contrarian Problem Selection
Most teams ask: “Which problem can we solve easily?”
We asked: “Which problem gives us an opportunity to be different?”
There is a strategic reason behind this. Suppose 50 teams choose relatively easy and popular problem statements. Even if your implementation is good, you are competing against a large number of similar-looking solutions. But imagine you choose a difficult problem that only a handful of teams are willing to explore. Suddenly, differentiation starts before development even begins. Your competition isn't automatically smaller—but your design space becomes less crowded. That is a huge advantage.
But there is a trap
Don't misunderstand this principle. Difficult does not automatically mean valuable. Choosing the hardest problem just because it is hard is stupid. The correct model is:
High difficulty + strong problem relevance + feasible execution = strategic opportunity
Not: High difficulty = guaranteed success.
Our decision filter
When evaluating a problem statement, ask:
| Question | Why it matters |
|---|---|
| Is this genuinely difficult? | Reduces the number of teams willing to attempt it |
| Is the problem important? | Prevents innovation from becoming useless complexity |
| Is the problem understandable? | Helps you communicate it to judges |
| Can we technically prototype it? | Keeps ambition grounded |
| Can we demonstrate it visually? | Makes evaluation easier |
| Can we build differentiation into it? | Prevents your solution from looking generic |
The ideal problem is not the hardest one. It is the one where difficulty creates room for differentiation.
3. The First Problem We Took Seriously: Argo Float Data
Our first major problem statement revolved around Argo floats and oceanographic data. At first glance, it looked like a data visualization problem.
That immediately raised another question: What would everyone else probably build?
The obvious answer was a dashboard. Show the floats. Show their locations. Display their information. Maybe add graphs. Done. But that solution didn't excite us.
So we asked a different question: What would happen if we treated the data itself as the product?
That changed everything. Instead of simply showing information about Argo floats, we worked with the underlying data generated by them. We downloaded individual datasets from thousands of floats. Approximately 10,453 float profiles eventually made their way onto my system. Then we encountered the first real engineering problem. The datasets were primarily in NetCDF (.nc) format, which was not convenient for the application we wanted to build. So instead of stopping at the difficulty, we created a conversion pipeline and transformed the data into formats our application could work with, including:
- JSON
- CSV
We then stored the collection locally in MongoDB and began building the application with Streamlit. At that moment, something important had happened. We were no longer discussing an idea. We had a system.
Mental Model #3: Build Before You Feel Ready
This became one of the strongest lessons from the entire journey. While many teams were still discussing concepts for the internal hackathon, we had already completed roughly 30% of our prototype, with approximately 35 features already present. Why? Because we did not wait for the perfect architecture. We built the first ugly version. We tested assumptions. We discovered limitations. We changed things. We learned from the prototype itself. This is fundamentally different from planning forever.
The common beginner mistake
A team spends two weeks discussing:
- What framework to use
- What database to use
- What the UI should look like
- What architecture would be perfect
- What future features might be required
And after all that planning… there is still no working prototype. That is dangerous in a hackathon. Because reality does not care about your architecture diagram. The prototype exposes the truth.
Our model
Instead of: Idea → Perfect plan → Implementation
we gradually learned to use:
Idea → Prototype → Discover problems → Improve → Integrate
The prototype became a learning machine.
4. Our Most Important Question: “What If?”
One pattern appeared repeatedly throughout our development. Someone would suggest something that sounded absurd. Something technically difficult. Something that would probably require more work than expected.
And someone would say: “That's impossible.”
Our response became surprisingly consistent: “Okay. Let's figure it out.”
Not: “Yes, definitely.”
Not: “We can obviously do it.”
Just: Let's break it down.
That distinction is incredibly important. Because unconventional thinking without technical discipline is just fantasy.
Mental Model #4: The “Impossible → Decompose” Framework
Whenever we encountered a seemingly impossible idea, we converted it into smaller questions. For example:
Instead of debating whether the idea was possible, we broke it down:
Where does the data come from?
↓
Parsing
How do we extract useful values?
↓
Transformation
How do we convert the data into a usable structure?
↓
Storage
Where do we store it?
↓
Computation
How do we calculate the required values?
↓
Visualization
How do we represent them in 3D?
↓
Interaction
How does the user explore the result?
↓
Performance
Can the system handle the data efficiently? Suddenly, something that sounded impossible became a sequence of engineering problems. That's the real trick.
Don't ask: “Can we build this?”
Ask: “What would have to be true for us to build this?”
That question is much more powerful.
5. Don't Build 35 Features. Build One Story
Having many features sounds impressive. But it can also destroy a project. Imagine presenting this:
“We have AI, We have ML, We have six maps, We have 3D visualization, We have analytics, We have prediction, We have quantum computing.”
The judge's next thought might be: “Okay… but why?”
This is where many hackathon projects collapse. Features are not the product. The relationship between the features is the product. Our own definition of a strong solution eventually became a six-part framework.
6. Our Six-Part “Perfect Solution” Model
1. Features Nobody Thinks Of
The first goal is surprise.
You want the evaluator to think: “How did they even think of that?”
This is where differentiation begins. But surprise is not enough.
2. Features Nobody Can Easily Replicate
A feature that another team can copy after watching your demo has little strategic value. Depth matters. Your advantage should come from:
- Data pipelines
- Technical integration
- Architecture
- Specialized computation
- Unique UX
- Domain understanding
The harder your system is to reproduce, the stronger your differentiation becomes.
3. Solve the Exact Problem
This is the most important constraint. A technically impressive feature that has nothing to do with the problem statement is not innovation. It is decoration. Every ambitious feature still needs a connection to the central problem.
4. Everything Must Point Toward One Goal
A powerful project should feel like one machine. Not 20 unrelated mini-projects. For us:
Data → analysis → prediction → visualization → understanding
Everything was connected.
5. Every Feature Must Have Meaning
A feature should exist because it serves a purpose.
Not because: “We need more features.”
This is a brutal rule and a useful one.
For every feature, ask: If we remove this, what value disappears?
If the answer is: “Nothing.”
Delete it.
6. Even Showcase Features Need a Reason
Hackathons are demonstrations as much as they are engineering exercises. Sometimes you want a feature because it creates a powerful demonstration moment. That's fine. But even your showcase features should still connect to the solution. The audience should never feel:
“They added that just to look cool.”
You can check our project here : click here
7. The Presentation: Five Minutes Was Supposed to Be Five Minutes
Then came the internal hackathon. The rules were brutal. Every team had approximately five minutes to present. Not five minutes and thirty seconds. Not five minutes and five seconds. Five minutes. Teams that crossed the limit were stopped in the middle of their presentations.
So naturally, we prepared. But something unexpected happened. We started presenting. Five minutes passed. Nobody stopped us. We continued. Ten minutes passed. Still nothing. We kept going.
We explained the problem. The data. The prototype. The visualizations. The architecture. The features. The reasoning. The connection between everything. The presentation continued for approximately twenty-four minutes. And the jury kept listening. They did not interrupt us. They did not stop us. And perhaps the most interesting part was this:
They did not ask us a single question.
That didn't happen because our project had nothing to question. It happened because our explanation had already answered many of the questions they would normally need to ask. This leads to another important mental model.
Mental Model #5: Answer the Judge's Next Question Before They Ask It
Don't build your presentation as:
Problem → Features → Thank You
Build it as:
You ask Question → You Answer it→ Next Question → Answer
That's when a presentation becomes powerful. The goal isn't to speak for 24 minutes. The goal is to make the judge want to keep listening.
8. Storytelling Is a Technical Skill
A common mistake among engineering teams is believing that presentation is separate from engineering. It isn't. A badly presented great project can lose. A brilliantly presented weak project can create temporary excitement but eventually falls apart under questioning.
The strongest combination is: Strong engineering + strong narrative
Your story should make the architecture feel inevitable.Turn scientific data into something users can explore. Now the technology isn't random anymore. It has a narrative.
Here's a simple technique you can use during SIH preparation.
Create a table like this:
| Feature | Problem it solves | User value | Demo value |
| Data conversion | Raw data is hard to use | Makes data processable | Shows engineering depth |
| ML prediction | Need future insight | Helps users interpret trends | Demonstrates intelligence |
| 3D visualization | Numbers are difficult to interpret | Makes patterns visible | Strong visual impact |
| Interactive maps | Geographic exploration is difficult | Makes data navigable | Strong presentation moment |
Now apply one rule: If you cannot explain a feature's purpose in one sentence, question whether it belongs.
This prevents the classic hackathon disease: Feature bloat.
9. The Biggest Lesson We Took Away
Looking back, our victory wasn't really about having more features. It wasn't about using more technologies. It wasn't because we worked longer hours. And it definitely wasn't because we discovered some secret hackathon trick. The deeper advantage was psychological. We became comfortable entering territory where the answer wasn't obvious. When everyone moved toward the safe idea, we were willing to investigate the uncomfortable one.
When someone said: “That's too difficult.”
We didn't interpret it as: “Don't do it.”
We interpreted it as: “Break it down.”
When a problem looked confusing, we didn't immediately run toward a simpler one.
We asked: “What is hiding inside this complexity?”
And when our project became technically complicated, we didn't accept a complicated user experience as inevitable.
We asked: “How can we hide the complexity?”
That became our actual competitive advantage. Not intelligence. Not technology. A way of thinking.
For you, try to become the team that has the clearest answer to five questions:
1. Why this problem?
2. Why this solution?
3. Why these technologies?
4. Why these features?
5. Why are you different?
If your entire project can answer those five questions coherently, you are already thinking at a different level.
The Beginning, Not the Ending
We cleared our internal hackathon. But the result itself wasn't the part I remember most. I remember the realization that our thinking had finally produced something visible. We had entered the room as six students with an unconventional approach. We walked out knowing that the approach could work.
For a competition where five minutes was supposed to be the boundary, our presentation eventually stretched to roughly twenty-four minutes because the jury kept listening, They didn't stop us, They didn't cut us off, They didn't need to interrupt the flow with questions And in that moment, the result became bigger than simply clearing an internal round.
We had discovered something.
Different thinking creates different outcomes.
But there is an important lesson hidden even deeper inside that statement. Being different is not the goal.
Being meaningfully different is.
Random creativity gets attention for a moment. Contrarian thinking finds opportunities. Systems thinking turns those opportunities into coherent solutions.Engineering turns those solutions into reality. UI/UX makes them understandable. Storytelling makes people care. And execution turns the whole thing into something memorable.
That was the beginning of our SIH journey.
Finally remember:
Your objective is not to build the biggest project.
Your objective is to build a project where every decision makes sense—and where the final result feels like something only your team could have built.
That is what we learned from our first SIH step.
And this was only the beginning.
You can follow me in: LinkedIn, GitHub, Instagram
— Abhinav, Abhinav Engineering Notes
Actually it was good
ReplyDelete